D1eter wrote: > I'm afraid I don't. I only know one such stream and only because I > create it myself.
The only online sources I have found are here: https://community.auralic.com/t/lossless-internet-radio-ogg-flac/852 https://www.hiresaudio.online/cd-quality-internet-radio/ I have used http://rod.frequence3.net/frequence3.flac.m3u once or twice for testing. They all seem to be regular 44100/48000 sample rate streams. > > In addition, one glitch remains: When I play the stream on the Touch and > then turn on a Radio that is synchronised with the Touch there should be > a brief pause and the stream should restart playing in sync on both. > This does not work consistently. I suspect that this stems from joining a 48kHz Radio into a pre-existing group operating at 96kHz. That, of necessity I think, requires the whole group to be restarted at the 48kHz sample rate. I wonder what would happen if you play the stream on the Radio, and then turn on the Touch. I've never had much success with a group that mixes 96kHz and 48kHz players when playing 96kHz flac files, too much rebuffering. That may stem from my having a somewhat underpowered server. So, I simply don't use 96kHz sample rate streams, I wouldn't hear the difference anyway. :) As a supplementary trick, you could choose to countermand the Radio's stricture that it will only accept a 48kHz stream by adding a custom conversion rule something like: Code: -------------------- ogf flc baby * # IFRD:{RESAMPLE=-r %d} [flac] --ogg -dcs -- $FILE$ | [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 - -------------------- This rule will only apply to a Radio, and will, I think, take precedence over any existing rule. The Radio will then operate "just as it used to", and receive a 96kHz sample rate stream. It uses the original conversion rule, but fools LMS into thinking that the required down sampling is taken care of. I fed a 88.2kHz sample rate stream to my Radio to remind myself of what issue I had previously observed. It is this: the sound effects have somewhat "tinky" sound to them, although the stream seems to play fine. I note that the Radio's ALSA subsystem down samples the stream to 48kHz, not the 44.1kHz that one might expect, and that may well contribute to to the "tinkiness". As regards updating LMS: if it should be found that the proposed new rule is not as reliable for the normal use case (presumably 44.1kHz/48kHz streams), then one could, perhaps, use the existing flc -> flc trick, and formulate the new rule as follows: Code: -------------------- ogf flc transcode * # IFRD:{RESAMPLE=-r %d} [flac] --ogg -dcs -- $FILE$ | [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ - -------------------- If my understanding is correct, that rule would only come into effect when resampling is actually required. But I haven't validated that, it would need testing. I would be surprised if the replacement of: [flac] -cs --ignore-chunk-sizes --totally-silent --compression-level-0 - with: [sox] -q --ignore-length -t wav - -t flac -C 0 $RESAMPLE$ - does introduce unreliability, but I am frequently surprised. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=111597 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
