GNOME Bugzilla – Bug 650691
[flacparse] regression playing some flac files
Last modified: 2011-11-24 14:59:44 UTC
Created attachment 188239 [details] Amarok's output with debugging variables exported I am having some weird problems with playing certain FLAC file using GStreamer backend in Phonon. Both commands from http://techbase.kde.org/Development/Tutorials/Debugging/Phonon do not work. I have attached output from Amarok with debugging variables exported.
Created attachment 188240 [details] first second of broken file flacparse regression (plays fine with flacdec) 0:00:00.690961188 14542 0x7fd74e3da300 ERROR flacparse gstflacparse.c:760:gst_flac_parse_handle_streaminfo:<flacparse0> Invalid minimum block size: 0
Let's just do this then (unless anyone has a better suggestion): commit e0cadab5c2a54acfa5ac607b854890fea74c013f Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Sun May 22 18:50:51 2011 +0100 flacparse: don't error out on invalid minimum_blocksize value in streaminfo header We don't use it, so may just as well accept an invalid value of 0 here, which is likely inconsequential anyway. https://bugzilla.gnome.org/show_bug.cgi?id=650691
There's more to this. Tim and Vincent have a longer sample file that exposes this issue. streaminfo header apparently implies variable block size (and has invalid min_blocksize value of 0?), even though the block size in practice is actually always the same afaict.
Is this fixed by this? commit 011c33e91ec56c64e26312cf5cdb60890a84d32e Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Nov 14 15:34:57 2011 +0000 flacparse: detect when a file lies about fixed block size If the sample/block number happens to be the same as the block size, we assume variable block size, and thus counters in samples in the headers. This can only get us a false positive for a block size of 1, which is invalid. We can get false negatives more often though (eg, if not starting at the start of the stream), but then that's already GIGO.
Ah, yes, forgot about the bug, sorry :) Now, this particular file sounds very odd at start, there's like a second of noise/corrupted like thing, but doesn't sound like total noise, and sounds the same with ffmpeg and VLC, so... I still get one hiccup in 0.10 near the start, but it doesn't happen in 0.11, so I'm tempted to just ignore it since the file is broken in the first place. If a valid file is found that does hiccup, then reopen (or open a new one).