What is the difference in the DAB+ AAC encodings?

[Chris]

Hi there,

I am experimenting with DAB+ audio in odr-dabenc because one of my receivers (a GRUNDIG pocket dab+ player) would refuse playing whatever stream was above 80kbps. Although dablin, welle.io and qt-dab wont have any problems, this portable device would show "Service not available" on this subchannel. So I checked out to see if there is any other difference except the kbps and I saw (in welle.io) that at a 80kBit/s stream is characterized as HE-AAC but a 128kBit/s stream is characterized as AAC-LC. So the conclusion could be that my handheld device would not the play AAC-LC codec, but it would be nice to know what is going on here on this section.

Is this a decision by odr-dabenc? Is there any parameter to use this other codec for higher bitrates and what are the differences?

Best Regards

Chris

[Matthias Brändli]

Hi Chris,

(I assume when you write odr-dabenc, you mean odr-audioenc.)

Some background:

The DAB+ standard specifies AAC-LC, HE-AAC (a.k.a. AAC-LC + SBR) and
HE-AACv2 (a.k.a. AAC-LC + SBR + PS). Depending on the bitrate, it makes
sense to switch the mode for quality reasons.

At high bitrates, SBR doesn't bring any benefit anymore. The threshold
is around 80kbps, but I'm not sure if it's 80 or 88. ODR-AudioEnc will
tell you at startup.

The threshold to enable PS is a again lower. Again, ODR-AudioEnc will
tell you.

You can override those automatic choices using --aaclc, --sbr and --ps.


About your observed receiver behaviour:

There's more than one way of doing the AAC bitstream that is used in
DAB+. Maybe your receiver is not compliant, because it is unable to
decode some valid bitstreams. Maybe ODR-AudioEnc is not compliant,
because it generates something that is not exactly valid but happens to
work with the majority of receivers. It is not always easy to
distinguish the two situations.


A few receiver limitations we know about, that might or might not apply
to your situation:

1. Maximum number of CUs: at high bitrates and with strong subchannel
protection, the number of Capacity Units used by your subchannel can be
too large for some receivers. Try different protection levels, and try
AAC-LC at lower bitrates to see.

2. 32kHz sampling rate is not well supported. Many receivers seem to
have issues with 32kHz. Best use 48kHz, which is more common anyway.

Hope this helps!
Cheers
mpb

> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crc-mmbtools/58bee903-ca08-4bcd-b36e-2eefaeebfdd5%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/58bee903-ca08-4bcd-b36e-2eefaeebfdd5%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Peter Whisker]

Hi

You can of course override the defaults with odr-audioenc switches:

         --aaclc                          Force the usage of AAC-LC (no SBR, no PS)
         --sbr                            Force the usage of SBR (HE-AAC)
         --ps                             Force the usage of SBR and PS (HE-AACv2)

The defaults are chosen to try to maximise the perceived quality at the chosen bitrate.

Peter

--

You received this message because you are subscribed to the Google Groups "mmbtools" group.

To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/58bee903-ca08-4bcd-b36e-2eefaeebfdd5%40googlegroups.com.

[Chris]

Hi guys,

1) Yes I was meaning odr-audioenc. I have done this mistake and in the commandline and it wouldnt be recognized and I was stairing at my screen asking myself what I wrote wrong.

2) Scenario 1 of your possible problems was the answer. The receiver could not handle so much CU's. When I lowered the protection to 2 it started playing. By the way, is there any easy way calculating CU's? Last time I was here and there lowering protections and kbps restarting until odr-dabmux would accept my configuration without not telling me I am exceeding my CU's :)

Thanks for giving the info on forcing a codec. I would like to make a remark here, that there is a lack of documentation in some switches and choices you have on encoding and multiplexing. Like I found by accident that there is a property for the protection profile and not only just the protection.

Currently I am using a Raspberry Pi with good cooling to encode 10 streams from the internet and multiplex them with odr-dabmux on the same board, and send them to an EasyDAB board, broadcasting all 10 local fm radio stations of my town on DAB with great success. I also tested HackRF but I couldnt get such a strong signal from it so I can amplify it as EasyDAB board does. But I strongly prefer EasyDAB because it does not need the use of dabmod that needs a strong machine. Using the encoders+debmux+dabmod would work, but would put the pi to its limits.

I also noticed that using padenc and the -P switch to get the icy text from a radio stream proves a little bit unstable. There are lots of times that for no reason, audioenc (or vlc - i dont know who exactly does this) will not write the new icy text to the text file so it can be read from padenc. Usually after some time, it will update every other song. When I set my radio automation to write to the text file directly (from a windows computer directly to a shared folder of my pi via smb), padenc would update it immediatelly.

odr-padenc -o /tmp/pad_kiss.fifo -t /home/pi/shared/SongAnnouncements/KISS/NowOnAir.txt -d /home/pi/shared/SongAnnouncements/KISS/MOT -p 80 &

odr-audioenc -D -v http://eco.onestreaming.com:8550 -r 48000 -c 2 -o tcp://localhost:9002 -l -b 80 -p 80 -P /tmp/pad_kiss.fifo

Well these are my findings so far. You have done a great job. DAB would be impossible if not for your project.

Best regards

Chris

[Peter Whisker]

Hi

I find B2 protection to actually work marginally better than A3 on my receivers and it saves a few CUs. I would personally go for 96k EEP-B2 (63 CU) over 88k EEP-A3 (66 CU) any day. The B protection only allows codec rates as multiple of 32k rather than 8k for the A series.

Broadcasters typically use EEP-A3.

Peter

--

You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/1c9de5ae-495c-4356-b2ee-7d63eb966a31%40googlegroups.com.

[Matthias Brändli]

Hi Chris,

glad you found the issue. And especially glad that it wasn't an bug in
the mmbTools :-)

> Thanks for giving the info on forcing a codec. I would like to make a> remark here, that there is a lack of documentation in some switches
and> choices you have on encoding and multiplexing. Like I found by
accident> that there is a property for the protection profile and not
only just> the protection.

The exhaustive description of options for ODR-DabMux configuration is in
doc/example.mux, doc/advanced.mux and doc/servicelinking.mux, depending
on what you're looking for.

For ODR-AudioEnc, I tried to cover a few common scenarios in the README,
and the --help output is intended to be exhaustive.

If you see that some important information is lacking in either the
README, the --help output, the PDF guide or anywhere else, please
improve it! Ideally sending me a patch with the changes, or even a text
blurb I can copy-paste to the right place is appreciated. Writing
documentation takes quite a lot of time!

From small typos to complete new chapters in the guide, I'd love to help
you contribute to the quality of the documentation.

> I also noticed that using padenc and the -P switch to get the icy text
> from a radio stream proves a little bit unstable. There are lots of
> times that for no reason, audioenc (or vlc - i dont know who exactly
> does this) will not write the new icy text to the text file so it can be
> read from padenc.

The ICY Text comes from VLC, but the "write to file" part is done by
ODR-AudioEnc.

> Usually after some time, it will update every other
> song. When I set my radio automation to write to the text file directly
> (from a windows computer directly to a shared folder of my pi via smb),
> padenc would update it immediatelly.

I believe that's a better approach in any case.

> Well these are my findings so far. You have done a great job. DAB would
> be impossible if not for your project.

Thanks for your report, always nice to hear where the tools are used!

Cheers
mpb

[Wayne Turner]

On Thursday, October 31, 2019 at 1:12:15 PM UTC, Matthias Brändli wrote:

> The ICY Text comes from VLC, but the "write to file" part is done by
> ODR-AudioEnc.

 Hi all, I have also encountered the same thing. I'm not a linux guru, but managed to get my test mux up and running, using Hack RF SDR. I am currently experimenting with the various stream types and different ways of encoding. One thing I do want to get going is accurate now playing DLS. It all seemed a bit too easy to get odr-audioenc to pick up the ICY text, write to a file for PadEnc to pickup and convert to then write into the stream!

Ideally I would like to avoid having a seperate process to grab the stream titles and then write to the txt file for PadEnc should I be using something other than VLC for AudioEnc to get the internet stream?

Thanks

W

[Matthias Brändli]

On 03/11/2019 21:31, 'Wayne Turner' via mmbtools wrote:
> It all seemed a bit too easy to get odr-audioenc to pick up the ICY
> text, write to a file for PadEnc to pickup and convert to then write
> into the stream!

Well that's the whole point of having the feature...

So if it doesn't work properly, either we fix it or we remove it!

What do you observe? Sometimes it prints the ICY-Text on screen, but
doesn't update the file?

mpb

[Wayne Turner]

On Monday, November 4, 2019 at 1:14:35 PM UTC, Matthias Brändli wrote:

On 03/11/2019 21:31, 'Wayne Turner' via mmbtools wrote:

> So if it doesn't work properly, either we fix it or we remove it!

My observation is that when odr-audioenc first starts up it gets the ICY text and writes it to the file. After this any further ICY updates are ignored. If I quit audioenc and then restart it, it updates the ICY text to the text file, but again after that nothing changes.

W

 

[Ulrik Brinck]

Hi Matthias and others,

> At high bitrates, SBR doesn't bring any benefit anymore. The threshold
> is around 80kbps, but I'm not sure if it's 80 or 88. ODR-AudioEnc will
> tell you at startup.

Apparently it's around 88 kbit/s according to this graph:
https://www.iis.fraunhofer.de/en/ff/amm/communication/aaceld/_jcr_content/contentPar/sectioncomponent/sectionParsys/textwithinlinedimage/imageComponent2/image.img.large.jpg/1548072577253/FraunhoferIIS-AAC-ELD-Quality-diagram-1000.jpg

(Taken from here: https://www.iis.fraunhofer.de/en/ff/amm/communication/aaceld.html )

But remember, this is audio bitrate, not DAB+ bitrate. So it could perhaps make sense to let ODR-AudioEnc use SBR as default even at 96 kbit/s DAB+ bitrate?

But one thing is what the books say, another thing is real world observations. Some time ago, we upgraded one of our DAB+ channels from 88 with SBR to 128 kbit/s without SBR, and to my surprise, it sounded worse than before. It is a radio channel with rock music, lots of drums and cymbals, and particular the cymbals suddenly sounded awful. So I added SBR back using the --sbr parameter, and then it sounds good.

So my observersion is that even at 128 kbit/s, ODR-AudioEnc can sound better with SBR than without it.

Then why is it sometimes not as the books say? I'm not sure, but I'm thinking that FDK-AAC (on which ODR-AudioEnc is built) might be different than other AAC codecs? In wikipedia, this is written about FCK-AAC:

"The FDK AAC encoder employs a more aggressive default low-pass filter than is used in other codecs. Higher frequencies are removed so that more bits are available to better describe sounds of lower frequencies, improving the overall quality for most combinations of recordings and listeners. In some, not completely rare, combinations the missing high frequencies are noticeable."
https://en.wikipedia.org/wiki/Fraunhofer_FDK_AAC

Perhaps this could be the reason?

Anyway, probably the best to do is to make your own observations. Try the different AAC encodings at your desired bitrate and pick whatever sounds best.

> 2. 32kHz sampling rate is not well supported. Many receivers seem to
> have issues with 32kHz. Best use 48kHz, which is more common anyway.

That surprises me... We're using 32 kHz on our channels here, because my observation is that with ODR-AudioEnc, 32 kHz sounds quite much better than 48 kHz at the same bitrate (I also remember an old thread in this group, in which others have made the same observation).

What are the issues with those receivers? Do they refuse to play it? Despite having had quite many different receivers betweens my hands for our trials here, I have never expeirenced a receiver which could not play 32 kHz. In the car (JVC KD-DB42) it takes slightly longer time from tuning in, until it begins to play at 32 kHz compared to 48 kHz, but that's all I have observed regarding 32 kHz.

Best regards,
Ulrik.

> To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/501ca96e-3185-cee4-0315-178feb33a1ec%40mpb.li.

[Matthias Brändli]

Hi Ulrik,

> But remember, this is audio bitrate, not DAB+ bitrate.

What do you mean by "audio bitrate" and "DAB+ bitrate" ?

> But one thing is what the books say, another thing is real world observations. Some time ago, we upgraded one of our DAB+ channels from 88 with SBR to 128 kbit/s without SBR, and to my surprise, it sounded worse than before.

FDK is not known to be excellent quality, and SBR seems to mask some
artefacts the AAC-LC codec creates.

Careful when reading quality assessments, what applies to one encoder
doesn't necessary apply to all of them.


I intend to add a configurable low-pass filter in ODR-AudioEnc before
the samples reach FDK-AAC, because I've been told that can help the
codec in some cases.

>> 2. 32kHz sampling rate is not well supported. Many receivers seem to
>> have issues with 32kHz. Best use 48kHz, which is more common anyway.
>
> That surprises me... We're using 32 kHz on our channels here, because my observation is that with ODR-AudioEnc, 32 kHz sounds quite much better than 48 kHz at the same bitrate (I also remember an old thread in this group, in which others have made the same observation).

Yes, if I recall correctly we reached the same conclusion too.

> What are the issues with those receivers? Do they refuse to play it?

I don't remember which ones exactly, but there were some car head-units
that just didn't play 32kHz services. Maybe someone from the list
remembers more details.

Maybe I should have written "some receivers" instead of "many
receivers", and sorry that I don't have data to back that claim.

Several times during discussions the idea came up to put up a database
(or even just a wiki page) with observations about receiver
(mis)behaviour, but nobody ever took the lead on that idea and started
doing it. It might have been useful now to answer your question... Any
takers? The wiki is here for that.

Cheers
mpb

[Ulrik Brinck]

Hi Matthias,

>> But remember, this is audio bitrate, not DAB+ bitrate.
>What do you mean by "audio bitrate" and "DAB+ bitrate" ?

By DAB+ bitrate I mean the bitrate set by the -b parameter for ODR-AudioEnc and again in the mux configuration.

By audio bitrate I mean the bitrate of the audio itself. It is lower than the DAB+ bitrate, because some of the assigned bandwidth is used for Reed-Solomon error correction and for PAD data (if used).

I can see that ODR-AudioEnc (at least v2.3.0 which I have here) defaults to HE-AAC up to 80 kbit/s and AAC-LC from 88 kbit/s. But at 88 kbit/s DAB+ bitrate, the audio bitrate becomes roughly 80 kbit/s, or even lower if a slideshow is broadcasted as PAD data, so HE-AAC might be a better choice there.

>Careful when reading quality assessments, what applies to one encoder
>doesn't necessary apply to all of them.

Yes, and the graph I had found appeared to be for a different variant of AAC, so I actually tried to correct myself in a new message, but it seems that Google Groups would not let me post almost-the-same message again. ;)

Best regards,
Ulrik.


----- Original Message -----
From: "'Matthias Brändli' via mmbtools" <crc-mm...@googlegroups.com>
To: <crc-mm...@googlegroups.com>
Sent: Tuesday, November 05, 2019 10:12 AM
Subject: Re: What is the difference in the DAB+ AAC encodings?

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/79380db1-44aa-0c8c-e0fa-2ae2a5b7813e%40mpb.li.

[Matthias Brändli]

Hi Wayne,

> My observation is that when odr-audioenc first starts up it gets the ICY
> text and writes it to the file. After this any further ICY updates are
> ignored.

I can't reproduce the issue with my streams. Can you give me the stream
URL so that I can try yours too?

Cheers
mpb

[Matthias Brändli]

Hi,

>> What do you mean by "audio bitrate" and "DAB+ bitrate" ?
>
> By DAB+ bitrate I mean the bitrate set by the -b parameter for ODR-AudioEnc and again in the mux configuration.
>
> By audio bitrate I mean the bitrate of the audio itself. It is lower than the DAB+ bitrate, because some of the assigned bandwidth is used for Reed-Solomon error correction and for PAD data (if used).

Ah ok I understand.

As an aside, that makes me wonder if RS error correction is accounted
for in the assigned bandwidth. I think not, because the bitrate
parameter is given to FDK, but the RS happens after encoding, inside
ODR-AudioEnc. It's probably not so important anyway.

But I agree that PAD bitrate + audio bitrate = DAB+ bitrate


> [...] but it seems that Google Groups would not let me post almost-the-same message again. ;)

... and that also confuses people like me who only use the email
interface to the group :-)

Cheers
mpb

[Ulrik Brinck]

Hi Matthias,

> As an aside, that makes me wonder if RS error correction is accounted
> for in the assigned bandwidth. I think not, because the bitrate
> parameter is given to FDK, but the RS happens after encoding, inside
> ODR-AudioEnc. It's probably not so important anyway.

The bitrate given by the -b parameter apparently includes Reed-Solomon. On the attached screenshot here, you can se how a 96 kbit/s service with slideshow is reported by Andreas Gsinn's DAB Player.

The service is configurated with -b 96, --sbr and --pad=58. The 96 kbit/s becomes 87.4 kbit/s after Reed-Solomon and then divided into 80.4 kbit/s for audio and 7.0 kbit/s for PAD.

> But I agree that PAD bitrate + audio bitrate = DAB+ bitrate

I would say PAD bitrate + audio bitrate + Reed-Solomon = DAB+ bitrate.

Best regards,
Ulrik.


----- Original Message -----
From: "'Matthias Brändli' via mmbtools" <crc-mm...@googlegroups.com>
To: <crc-mm...@googlegroups.com>
Sent: Tuesday, November 05, 2019 11:20 AM
Subject: Re: What is the difference in the DAB+ AAC encodings?

> --
> You received this message because you are subscribed to the Google Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/4267db2b-1ae3-9173-9f85-e130d615cfd8%40mpb.li.

[Wayne Turner]

Hi URL is http://195.110.184.41:7002/ is not my stream as such. I noticed all titles start with Now Playing: so perhaps that is the issue.

Thanks

W 

[Wayne Turner]

On Tuesday, November 5, 2019 at 11:08:50 AM UTC, Wayne Turner wrote:

Hi URL is http://195.110.184.41:7002/ is not my stream as such. I noticed all titles start with Now Playing: so perhaps that is the issue.

Thanks

W

correction all tracks start with On Air Now: EG 

On Air Now:Put Your Hands Up 4 Detroit by Fedde Le Grand

 

[Wayne Turner]

Hi Matthias,

 I found the VLC debug and you are correct it does notice the ICY change, just doesn't write it to the nominated txt file. See below

[00007fbd40001410] main encoder debug: using encoder module "araw"

[00007fbd54002650] main stream out debug: input 'f32l' 44100 Hz Stereo frame=1 samples/8 bytes

[00007fbd54002650] main stream out debug: conversion: 'f32l'->'f32l' 44100 Hz->44100 Hz Stereo->Stereo

[00007fbd54002650] main stream out debug: conversion pipeline complete

[00007fbd40015af0] main audio resampler debug: looking for audio resampler module matching "any": 4 candidates

[00007fbd40015af0] main audio resampler debug: using audio resampler module "samplerate"

In: [ =====|=====-]      [00007fbd54004ef0] http stream debug: New Icy-Title=On Air Now:Heaven by The Vision & Andreya Triana

In: [ =====|===== ]      ^C

highuser@test-debian1:/usr/local/bin# cat hot.txt

On Air Now:Hot Evenings

However if I restart it, it will pick up the new title and write it to hot.txt no problem.

I'm not an expert at compiling perhaps its the version I am running, the details are below:-

odr-audioenc -v 'http://195.110.184.41:7002' -D --dab -r 48000 -c 2 -o 'tcp://127.0.0.1:9001' -l -b 128 -p 6 pP /tmp/pad.fifo -w hot.txt

Welcome to ODR-AudioEnc v2.4.1, compiled at Sep  8 2019, 17:52:16

  http://opendigitalradio.org

Initialising VLC...

You are using VLC with size_t size callbacks

[00005589846e6100] vlcpulse audio output error: PulseAudio server connection failure: Connection refused

Setting outbuf size to 4092

Starting encoding

toolame-dab encode_init(): using tablenum 0 with sblimit 27

[00007f2158006940] prefetch stream error: unimplemented query (264) in control

In: [ -====|===== ]      ^C

Regards

W

[Ash Elford]

"I don't remember which ones exactly, but there were some car head-units

that just didn't play 32kHz services. Maybe someone from the list
remembers more details."

Hi everyone,

I found that using the 32kHz sample rate with the ODR encoder caused issues with certain BMW/Mini DAB radios - the radios would report no signal on 32kHz, but would work if retuned several times (totally random). Using the Radioscape DAB+ encoder at 32kHz I don't have this issue, so there must be something not quite right with the ODR encoder.

I am also aware of distorted audio on headunits made by Kenwood at 32kHz.

It's a shame, because I do believe at lower bitrates that 32kHz sample rates is a good choice.

Anyway, hope this helps.

Ash

--
You received this message because you are subscribed to the Google Groups "mmbtools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crc-mmbtools...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crc-mmbtools/79380db1-44aa-0c8c-e0fa-2ae2a5b7813e%40mpb.li.

[Claus Nielsen]

Hello,

I must agree with the 32 kHz observations - it does indeed sound a lot better.

I never had any problems with recivers not being able to decode 32 kHz - I did get

one report about an older carradio (forgot the brand) that was not able to decode 32 kHz with SBR enabled but

AAC-LC 32 kHz worked fine on this particular reciever.

But a low pass filter in ODR-AudioEnc would be great.

Cheers,

Claus Juul Nielsen

Denmark

To unsubscribe from this group and stop receiving emails from it, send an email to crc-mm...@googlegroups.com.

[Stefan Pöschel]

Hmm, I tried this stream some days ago and I had no issues with an ICY
text update using the VLC input....this issue does not apply for all ICY
updates of a webstream, does it?

Am 05.11.19 um 12:23 schrieb 'Wayne Turner' via mmbtools:

>
>
> On Tuesday, November 5, 2019 at 11:08:50 AM UTC, Wayne Turner wrote:
>
>
> Hi URL is http://195.110.184.41:7002/ is not my stream as such. I
> noticed all titles start with Now Playing: so perhaps that is the issue.
>
> Thanks
>
> W
>
> correction all tracks start with On Air Now: EG 

> *On Air Now:Put Your Hands Up 4 Detroit by Fedde Le Grand
> <http://195.110.184.41:7002/currentsong?sid=1>*

>
>  
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to crc-mmbtools...@googlegroups.com
> <mailto:crc-mmbtools...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/crc-mmbtools/8ad1c93d-8120-4c81-b974-49d6df872055%40googlegroups.com
> <https://groups.google.com/d/msgid/crc-mmbtools/8ad1c93d-8120-4c81-b974-49d6df872055%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Wayne Turner]

Hi Stefan, yes odraudioenc does recognise the ICY title updates, you can see this if you enable debug verbose. However it doesn't seem to update the text file. 

Regards

W

On Wednesday, November 13, 2019 at 7:38:53 PM UTC, Stefan Pöschel wrote:

Hmm, I tried this stream some days ago and I had no issues with an ICY
text update using the VLC input....this issue does not apply for all ICY
updates of a webstream, does it?

Am 05.11.19 um 12:23 schrieb 'Wayne Turner' via mmbtools:
>
>
> On Tuesday, November 5, 2019 at 11:08:50 AM UTC, Wayne Turner wrote:
>
>
>     Hi URL is http://195.110.184.41:7002/ is not my stream as such. I
>     noticed all titles start with Now Playing: so perhaps that is the issue.
>
>     Thanks
>
>     W
>
> correction all tracks start with On Air Now: EG 
> *On Air Now:Put Your Hands Up 4 Detroit by Fedde Le Grand
> <http://195.110.184.41:7002/currentsong?sid=1>*
>
>  
>
> --
> You received this message because you are subscribed to the Google
> Groups "mmbtools" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to crc-mm...@googlegroups.com
> <mailto:crc-mmbtools+unsub...@googlegroups.com>.

[Eddy pe9ghz]

I'm obverving the same issue with the latest odr-audioenc sourcecode pulled from git. ODR-AudioEnc v2.4.1-22-ge4b4e7c, compiled at Nov 28 2019, 14:45:54

The ICY update is received but not repeatedly written to the textfile.

An older build of odr-audioenc which I've got running on my private box does seem to update the DLS text file every time. This is from a while back:

 ODR-AudioEnc v2.2.0, compiled at Dec 13 2017, 22:16:43