Bugzilla – Bug 4463
ReplayGain on 24/96 FLAC not supported
Last modified: 2009-09-08 09:16:20 UTC
The FLAC encoder does not support adding ReplayGain metadata to 24 bit, 96 kHz material. (N.B. I haven't tried metaflac.) foobar2000 0.9.4.1 does, but the files do not play back properly on the Transporter - after 30 seconds or a minute, playback gets broken up and choppy. This is not caused by an empty buffer, the same FLAC without RG plays fine as does the source WAV, plus Server & Network Health shows no issues. I cannot provide the affected files on the bug tracking system as they are 149 and 178 MB, but if you would like to get them, e-mail me.
i have a few flac's (48 and 96 khz, 24bit) with title + album RG set by fb2k 0.9.3.1 (some change in the latest version?) in the range from -5db to +1db. i experienced no drop outs or breaks related to replay gain settings. My steps: wav -> (optional: resample 192khz to 96khz wav-files) -> command-line-flac -> use mp3tag for tagging the flac -> open fb2k to verify all settings (sample rate, bit depth, tags, file can be played) + add replay-gain-settings -> move to music library -> enjoy the latest addition :-) SlimServer version: 6.5.1-nightly/linux/debian (one or two weeks old) Transporter firmware: 22
Did you listen to the whole track? This took some time to be apparent.
yes, i did. the longest track plays over 8 minutes. Usually (see below) i can listen to an album without any drop outs. I must admit i was a little bit surprised everything's working so fine: - WLAN keeps up with 3Mbit/s bitrate (as long as nothing else uses too much bandwidth - copying large files or streaming video is not recommended :-) - flac gapless + visualizer (VU meter) works - analog out (balanced) + digital out (aes/ebu into primare processor) works I even verified multiple times that no transcoding is taking place... You mentioned flac files 150MB in size. How long is this track? 6min? My 8 min one uses 200MB
One track is 170 MB and is 8:32, the other is 142 MB and is 6:32. Both were encoded using FLAC 1.1.2. OK, I'll try the latest nightly with the new Transporter firmware and report back.
Nope, problem persists with latest nightly: SlimServer Version: 6.5.1 - 10591 - Windows XP - EN - cp1252 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt and Transporter firmware 22.
Just to make sure, you are playing these with your 'file types' page set up for firmware decode of the flac file? I'm seeing some strange symptoms, but I'm still in the process of trying to figure out why they are happening what files are affected, and especially if the foobar tags are screwing up the file in some way.
Yes, file types shows that no transcoding is taking place. Native FLAC decoding. Markus Schiegl was nice enough to supply me with one of his 24/96 FLACs with RG. It's *almost* perfect, no choppiness 30 sec - 1 min in, but there is a noticeable, repeatable choppy/fluttery/staticky defect near the very beginning. It's consistently there, but the defect doesn't sound indentical every time. I have not confirmed whether this is caused by a buffer underrun as the FLAC loads. I also have yet to remove the RG and see if the defect remains.
cc'ing Richard
Confirmed - the defect I hear with Markus Schiegl's file goes away when I remove RG. I also confirmed it's not caused by a buffer underrun.
Is it possible you could upload it (or a chunk of it) for Richard to work with?
Created attachment 1712 [details] 2 MB chunk of affected 24/96 FLAC with RG Not sure if this came out correctly. I don't know if FLAC likes to be broken up like this, and foobar plays it but errors out at the end. However, in the complete file, this is the section where the fluttering/skipping is heard.
I should mention the complete file is 132 MB! That's 24/96 FLAC for ya... If you need to get that, we'll have to find an alternate way of uploading it. Thanks.
Mark, that 2MB chunk plays fine for me. Can you give me access to the whole file, please email richard at slimdevices dot com and well work out how I can download it. How did you apply the replay gain to the track. I tried metaflac with one of my test tracks it that says it does not support 96k files? It is possible that the CPU is running out of cycles, and this is causing the choppy playback. I had to optimise FLAC for 24/96 playback, looks like a little more might be required.
Thanks Mark I now have the test tracks. The problem is due to the Transporter CPU running out of cycles when both replay again _and_ the spectrum analyser screensaver are enabled. It seems to work fine with either replay gain _or_ the spectrum anayser. I have profiled the code and it appears that no quick optimisations are possible, will look at this again another day.
confirmed. i get dropouts using the spectrum analyser, whereas the vu-meter does not cause this problem. btw. no problem for me (at the moment), as i've never used the spectrum analyser.
As proposed in http://forums.slimdevices.com/showthread.php?p=246642#post246642 a short update on this case: Please have a look at bug https://bugs-archive.lyrion.org/show_bug.cgi?id=4562 - probably a duplicate/more visible one. Issue https://bugs-archive.lyrion.org/show_bug.cgi?id=4886 talks about possible speedups in the decoder library by Josh Coalson and has workaround i modified a little bit: convert.conf #flc flc * * # - flc flc * * [flac] -dcs --skip=$START$ --until=$END$ -- $FILE$ | [flac] -cs --lax --totally-silent --compression-level-0 - I had to use the --lax option for 88.2khz encoding - which works so far. thanks!
Sean: do your recent changes fix this?
Have not tested yet, but should be fixed by the CPU optimizations in the new_audio branch.
Believed to be fixed in trunk 17060 / firmware 40. Need someone to confirm please.
i can confirm there are no drop-outs on my system anymore: - with enabled replay gain (-9 db) - spectrum analyser (overlayed or standalone) - 96/24 file with 3500kbps (according to SC) I've checked most of my previously known problematic tracks great work! What about your tracks Mark?
Thanks for confirming Markus. Closing this bug.
Changing fixed target to 7.1 as FW 40 will be released then, not in 7.0.1
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.