Bugzilla – Bug 2651
Gross distortion with FLAC files - ReplayGain
Last modified: 2008-09-15 14:38:10 UTC
I noticed after upgrading to 6.2 of possible degraded sound quality at certain frequencies. It is not particularly definitive so I ignored it for a while. Nearly all my music files are FLAC encoded from 44.1Khz CDs. However, recently I had one CD encoded with FLAC that had the entire CD sounding grossly distorted. The distortion is extremely nasty and un-listenable, I thought either my newish Naim amp was burned out or my Celestion A1 speakers had blown. It is a Bach Solo Cello CD from ECM label (Thomas Dememga, JS Bach/Zimmerman), It happens like this: (1) NASTY Distortion at all volume levels and both channels when playing in FLAC mode. (2) Tried playing same FLACs in PC (Media Monkey) and played normally with no same distortions (3) I tried uncompressing one of the files back to WAV and it played OK with no distortions (4) Tried tested it in two 6.22 (Windows) nightly builds (Nov 28 and Nov 26) with same (distorted results.) (5) Tried 6.5 (Windows) Nov 28 with same (distorted results) (5) Tried 6.1.1 - 3774 Linux build, No Problem! So this problem seems to be peculiar to 6.2.2.and FLAC files, and only some FLAC files. The other FLAC files seem to be OK but they seem to sound a little worse to me. System configs: Windows Machine: IBM Thinkpad T30 1GB RAM �C (Windows XP SP2) Linux Machine: Buffalo LANStation 250GB Amplifier: Naim Nait 5i Speakers: Celestion A-1 / Harbeth LS3/5A Any ideas? It is very noticeable, I can upload FLAC file if needed.
6.2.1 is not a valid target, since it is already out. leaving blank to flag it for review.
(In reply to comment #1) > 6.2.1 is not a valid target, since it is already out. leaving blank to flag it > for review. Sorry was this for me? I did not understand the message. I started a thread in the Audiophile section and I think Radish correctly identified this as a Replay Gain issue. I turned off RG and the problem went away. You may want to look at how SB handles RG, I can send you the FLAC files if you want. John
The message was a comment for this report only. It was an explanation of why I changed the target milestone field, which should be set by SD at some point. If you have a file that can be used to reproduce the bug, please do attach it to this report. If it is too small, Dan can give you information later on where to upload the file.
Could you please attach one of the files in question to this bug? If possible - the output of "metaflac --list" is all that's needed. Thanks.
Also - what tagging program did you use to set the ReplayGain tags?
(In reply to comment #5) > Also - what tagging program did you use to set the ReplayGain tags? I used FLAC Frontend V1.71 The following is the Metatag Output: --------------------------- METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minumum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 1080 bytes maximum framesize: 10602 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 9305100 MD5 signature: 31d5f28ec7260e404d84b009aebe5d5c METADATA block #1 type: 3 (SEEKTABLE) is last: false length: 378 seek points: 21 point 0: sample_number=0, stream_offset=0, frame_samples=4608 point 1: sample_number=442368, stream_offset=677605, frame_samples=4608 point 2: sample_number=884736, stream_offset=1450132, frame_samples=4608 point 3: sample_number=1327104, stream_offset=2237002, frame_samples=4608 point 4: sample_number=1769472, stream_offset=3000288, frame_samples=4608 point 5: sample_number=2211840, stream_offset=3783479, frame_samples=4608 point 6: sample_number=2654208, stream_offset=4456892, frame_samples=4608 point 7: sample_number=3101184, stream_offset=5190717, frame_samples=4608 point 8: sample_number=3543552, stream_offset=5961433, frame_samples=4608 point 9: sample_number=3985920, stream_offset=6713116, frame_samples=4608 point 10: sample_number=4428288, stream_offset=7498113, frame_samples=4608 point 11: sample_number=4870656, stream_offset=8180634, frame_samples=4608 point 12: sample_number=5313024, stream_offset=8882070, frame_samples=4608 point 13: sample_number=5760000, stream_offset=9629883, frame_samples=4608 point 14: sample_number=6202368, stream_offset=10333392, frame_samples=4608 point 15: sample_number=6644736, stream_offset=11132372, frame_samples=4608 point 16: sample_number=7087104, stream_offset=11822035, frame_samples=4608 point 17: sample_number=7529472, stream_offset=12552065, frame_samples=4608 point 18: sample_number=7971840, stream_offset=13255762, frame_samples=4608 point 19: sample_number=8418816, stream_offset=14017710, frame_samples=4608 point 20: sample_number=8861184, stream_offset=14772367, frame_samples=4608 METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 437 vendor string: reference libFLAC 1.1.0 20030126 comments: 12 comment[0]: TITLE=JS Bach,Suite Nr.2 in d-Moll (BMV 1008),Thomas Demenga-2 comment[1]: ARTIST=Bach,Zimmermannm comment[2]: ALBUM=Bach, Zimmermann comment[3]: GENRE=Classical comment[4]: COMMENT=Encoded by FLAC v1.1.2a with FLAC Frontend v1.7.1 comment[5]: ENSEMBLE=Bach,Zimmermannm comment[6]: TRACKNUMBER=2 comment[7]: DATE=1996 comment[8]: REPLAYGAIN_TRACK_PEAK=0.81115723 comment[9]: REPLAYGAIN_TRACK_GAIN=0.21 dB comment[10]: REPLAYGAIN_ALBUM_PEAK=0.81115723 comment[11]: REPLAYGAIN_ALBUM_GAIN=+0.21 dB METADATA block #3 type: 1 (PADDING) is last: true length: 3847
I have an idea of what might be happening. At least, this is what I think was happening to me. If you encode FLAC files one at a time with the --replay-gain tag, the album gain value is set to the track gain value. You have to subsequently use metaflac --add-replay-gain on an album's files in order to add a proper album gain value. But if you don't use metaflac and leave the album and track gains the same, you can have a problem. It appears SlimServer stores the album gain on a per-album basis, rather than a per-track basis like it does for the track gain. So what happens is that the album gain for an album is set to the track gain for one of the tracks. Now, suppose that track was quiet and had a large track gain. When you go to play an album with "Smart Gain" enabled, that large gain will be applied to loud tracks, causing distortion. A better approach might be to store the album gain values on a per-track basis, as with the track gain values. This would prevent the distortion by effectively using each track's track gain value when playing albums where the album gain value hasn't been properly calculated.
I've just experienced this bug too. I queued up a song from an album, listened part way through, then added another one from the same album. When the second song started playing, I got the same gross distortion and very high volume levels described above (this was over a digital coax connection that already had its volume set at 40, too). It turns out that for whatever reason all the songs on this album have the Album gain tag set to 64.82db. ReplayGain tags for individual songs are more reasonable: about -6db to -8db. At higher listening volumes, this problem could damage equipment, so I'm hoping some sanity-checking can be added to the replaygain settings. (By the way - I love my Squeezebox. Thanks for a great product!)
Is this still an issue with the latest 6.2.2 nightly builds? Thanks.
I'm closing this as it doesn't appear to be a SlimServer issue. If someone is still seeing this with the latest 6.2.2 nightly - please upload a test file to ftp://electricrain.com/incoming/ and let me know. Thanks.