Bugzilla – Bug 9677
FLAC -> MP3 transcoding not fast enough
Last modified: 2011-01-13 02:00:28 UTC
When transcoding is enabled and set to a very low bitrate (64k) there is a gap between playback of songs. Albums are in flac and gapless playback works fine when transcoding is disabled or set to a higher bitrate.
I've verified this bug with Steven... Tried transcoding with both Lame 3.97 and 3.98 with the same behavior.
How much of a gap? Are we talking about < 100ms or something more? I am wondering if this is some kind of failure of the Lame/MP3-gapless mechanism or more-simply that the cost of transcoding is sufficiently high that the next track is not ready in time. Actually, maybe lame cannot add the necessary gapless header when transcoding from stdin. I suspect that true gapless may not be possible in this case.
Without testing, I would guess LAME does not add any header in this case. The header is usually added only after fully encoding a track, when it knows the padding (end) value.
Steven notes the gap is longer the smaller you make the bitrate, on the order of 2 seconds or more.
I think the problem here is that the FLAC -> MP3 transcoding is not happening fast enough to fill the initial autostart buffer. It should be transcoding as fast as possible to fill the buffer, but for some reason it's not. That's why lower bitrate MP3 adds more of a delay.
Lame is pretty CPU-intensive. On my slow system it struggled to encode in real time at any decent quality level.
Really? On my laptop it can encode to 64k MP3 about 12.5x real-time, using the same command line flags as convert.conf (-q 9 -v -B 64)
The 'q9' is the key. I usually use at least '-q5' as find '-q9' sounds pretty poor.
Steven, Annette, what quality level were you using? Do you still see this with 7.3.3? There were some changes to the piplining usage for transcoding that could possibly have helped a bit. But note, you will not get true gapless with this transcoding.