Convert Mp3 to FLAC

Well yes it is exactly that! The Naim DACs does a sterling job with even lower resolution audio files but it is that loss of clarity what it is about. Better detail, more clarity, more soundstage. If you can hear that difference then it becomes hard to go back from lossless quality.

If you cannot hear a difference between local lossless and online lossless streaming then it is probably not going to change if you test more. Unless you encounter something where they are different recordings all together.

Personally I hear no difference between local and online on my Star. But I am streaming over 500 Mbps fibre with Blue Jeans Cat6e cable. Perhaps that is what makes the difference. Also the Star is not as good as an NDX2 and nowehere as good as an ND555 so it may be that on higher end equipment the difference becomes more revealing.

Hi @anon44169596, it would mean that both routes will sound identical. The bytes are the same and go through the same network path from the local router to the DAC, so there would be no practical or theoretical difference between them that could be translated into audible effects.

My point was that others had referred to latency online causing the sort of problems you had described, while your reference to .wav files related to local not online streaming. I have no idea if latency is indeed the cause of your problems, but if nothing else I would expect latency on a closed network at home to be pretty consistent, whereas I know that latency across the internet can vary quite significantly even when measured just a few second apart. Might it be possible that there are simply periodic occasions when latency increases too much, or possibly even whatever is causing the latency to change have an effect itself? (I don’t have detailed awareness in thus area).

1 Like

When the latency becomes too high packages are not received in time to refill the buffer, which means the audio will simply stop playing for a second. No data equals no music, it wouldn’t mean that the stream would keep playing but with a lower quality.

When there is not a serious shortage of buffer space available on the streaming device (e.g. less than 1 megabyte), any latency up to for instance 1 second (which is very high) should generally not be a problem.

All the streaming networks use CDN’s (content delivery networks), which means they have gateways around the world to offer low local latency. So it’s very rare to have such a high latency that it would be an issue.

For example, the latency from my home ADSL connection, which is not very stable, to Japan is between 250-450ms:

64 bytes from rakuten.co.jp (133.237.16.234): icmp_seq=1 ttl=229 time=259 ms
64 bytes from rakuten.co.jp (133.237.16.234): icmp_seq=2 ttl=229 time=382 ms   
64 bytes from rakuten.co.jp (133.237.16.234): icmp_seq=3 ttl=229 time=259 ms
64 bytes from rakuten.co.jp (133.237.16.234): icmp_seq=4 ttl=229 time=421 ms
64 bytes from rakuten.co.jp (133.237.16.234): icmp_seq=5 ttl=229 time=258 ms

Which would be just fine for audio streaming. Tidal which uses a CDN has a much lower latency, between 15-60ms on my home connection:

64 bytes from 65.9.73.93: icmp_seq=1 ttl=244 time=34.9 ms
64 bytes from 65.9.73.93: icmp_seq=2 ttl=244 time=66.0 ms
64 bytes from 65.9.73.93: icmp_seq=3 ttl=244 time=13.2 ms
64 bytes from 65.9.73.93: icmp_seq=4 ttl=244 time=44.7 ms
64 bytes from 65.9.73.93: icmp_seq=5 ttl=244 time=13.1 ms
1 Like

There seems to be some confusion going on, apparently because different questions/discussions are not kept separate. As far as I can tell, it’s these:

  1. The new streamers have a 50MB buffer, so are not affected by short-term bandwidth variation on the internet uplink causing drop-outs

  2. The new streamers have a stronger CPU performance and other improvements, so streaming FLAC to them instead of WAV, and letting the streamer do the decompression work, is generally considered not to result in SQ difference.

  3. The old streamers had a small buffer because the design target was LAN streaming where intermittent bandwidth changes (and latency too if it matters) are less of a problem.
    (And Naim might have underestimated a bit I guess - for the price)

  4. The small buffer in the old streamers made it therefore difficult to cope with the variations in online streaming data delivery.

  5. The old streamers’ less powerful computing power had two effects:
    a. Getting online streaming platforms to work well was difficult, in part because of the mentioned buffer size put possibly in part also to run the required software. In any case, accommodating space requirements for both Tidal and Qobuz proved impossible.
    b. Streaming FLAC and letting the streamer do the decompression work taxed the computing platform more, possibly causing audible differences to WAV.

  6. Therefore, WAV is preferred to stream to the old streamers, but this is for LAN streaming, which can still cope with it despite the buffer size. It was never recommended for online streaming as far as I can tell (nor do I know of such an option)

2 Likes

I would be interested to know how much buffer space the first gen streamers actually had, does anyone here know that?

I am now wondering if the sound services don’t drop down to a lower quality when this happens. Like YouTube Will goes blocky.

If it does that it could explain the source of the belief that it is worse. If on a low bandwidth the quality is dropped. Then it would compare unfavorably with local.

1 Like

That is only possible with a progressive (lossy) source, a lossless source like FLAC or WAV cannot be downgraded in case of a poor connection.

Youtube or Netflix drop a 1080p stream down to 240p if the connection breaks up, that is where the blockiness comes from.

Yeah but both services have baseline sub options. So there has to be AAC versions as well?

Excellent summary. Thank you. I think its OK that different conversations are occurring because it all is relevant. I am personally learning. For me the big question that has been opened up is whether I can reach best SQ from my local Zen against streaming Tidal etc. It seems that the main feeling is that streaming high quality offers the same or better than same quality. Which is good. Because even with low internet connection of 20mbps I have assured that I can get good results

Yes that’s true, but those are different codecs, so it would mean having to stop the FLAC completely and start an MP3 or AAC stream. It wouldn’t be possible to do this while keeping the audio streaming.

MP4 for instance has progressive options built into the standard, so it can improve or reduce the quality for every frame while playing:

2 Likes

Certainly, it was just that it increasingly got all thrown into one pot although at least most participants actually know these things just as well as I do or better (because I learned it from them, e.g. IB and ChrisSU), so I just thought a reminder might help to keep it separate for everyone’s benefit :slight_smile:

Do you mean that the price with regards to the old streamers was too high given their relative market quality? I ask as interested as I am not sure what alternative was available at the time. For a ‘better’ price against sound. Was early tech maybe

Not me! But learning fast

Yeah that is true and a total shot in the dark. Trying to exhaust all options before having to accept that I am cloth eared. Cause I have quite a few local files and I really don’t hear the difference.

1 Like

No, I just meant that even for LAN streaming a bit more buffer might have been a good idea, a few MB might have made a difference later, and given the price of the units it may have been possible. But certainly they did their best under the known circumstances (no online streaming existing). And to be fair it was their first attempt. The new platform seems to have learned the lesson and to me it is difficult to see an online streaming scenario that it will not cope with for a long time, maybe ever.

To be fair, online radio certainly was a thing at the time of the NDX launch, and it’s one of the marketed features of the device. There is not that much difference between a 320kbit/s radio stream and a FLAC with an average bitrate of about 700kbit/s.

I think the main problem might have been that the older streamers shared the buffer RAM, so when new services were introduced such as Tidal which occupied valuable memory space, there was less space available for buffering. I could be wrong about this though, it’s just an assumption. But a safe approach would be to have dedicated memory available for buffering, which might not have been the case here.

Most streams in the Naim radio are like 128 kbit even today, though. And according to the Tidal webpage:

HiFi - Lossless CD quality (1411kbps or 16bit / 44.1kHz).

(And yes, I did allow for Naim underestimating it a bit maybe)

1411kbit is the maximum yes, when nothing can be compressed further, in that case it is equal to a WAV. But FLAC itself is variable bitrate and it changes depending on the amount of audio data that needs to be played. When there is less happening in the music there is less data, and this reduces the bitrate. If you play soft music with not much action you will notice the bitrate will drop to 700-800 or even 400-500 in some cases.

Sure, but the old streamers had to be made to work with the worst case obviously. Anyways, I still think arguably that even 400-500 is way more than internet radio used. And the difference between a 320kbit/s radio stream and a FLAC with an average bitrate of about 700kbit/s is that the latter is more than twice as much data :slight_smile: