Re: [Rhythmbox-devel] FLAC files produced by rhythmbox are very malformed

[Jonathan Matthew <jonathan d14n org>]

On Mon, Aug 14, 2017 at 08:20:33PM +1000, Jonathan Matthew wrote:
> On Sat, Aug 12, 2017 at 07:18:42PM +0000, Nick H wrote:
> > Hi all,
> >
> >
> > A few months back this bug started, while there was a huge gvfs + udisks change over causing even 
> > nautilus to not be able to read CD's. I've held off till now on reaching out until that died down a bit 
> > however the bug still persists. Any track I rip within Rhythmbox produces malformed FLACs (with various 
> > brand new CDs, and across different optical drives).
> >
> >
> > Most notably is that this is a problem solely with FLAC's ripped from Rhythmbox and SoundJuicer. 
> > Cdparanoia rips wav's just fine, and those can be converted to FLACs that work just fine.
> >
> >
> > The symptoms of the bug are fairly troubling. The metadata container cannot be updated, and therefore the 
> > files have literally no metadata in Rhythmbox, nor can it be set from any program. Running flac -d on the 
> > file fails and produces the following error: "ERROR while decoding metadata                     state = 
> > FLAC__STREAM_DECODER_END_OF_STREAM" and running metaflac from command line produces (for a random sample 
> > file) 258599 lines of what looks like hexdump output. A metaflac on SoundJuicer's looks like normal 
> > output but also fails to decode. If you "flac -Fd" on either Rhythmbox or SoundJuicer's FLAC file and try 
> > to convert it back, it reports errors as well about expected EOF's, so it looks like something's not 
> > quite right.
> >
> >
> > The back-end looks like it's calling to a gnome library to rip these tracks, but I'm not too familiar 
> > with the Rhythmbox codebase to say for sure. Can someone comment on how these files are produced? I'd 
> > like to see this bug fixed, and am willing to help but could use somewhere to start.
>
>
> Rhythmbox and Soundjuicer use GStreamer for media encoding.  Without knowing
> which operating system or distribution you're using, or what versions you're
> using of any of the software involved, it's hard to say what the timing of any
> of this means.
>
> You can roughly simulate the encoding pipeline used by running something like this:
>
> $ gst-launch-1.0 audiotestsrc num-buffers=100 ! taginject tags="title=test" ! audioconvert ! 
> audio/x-raw,channels=2,format=S16LE ! flacenc ! filesink location=test.flac
>
> which produces a working flac file here.

This is apparently a bug in GStreamer's flacparse element, so the above pipeline wouldn't trigger it.

GStreamer developers are discussing fixing the bug here: https://bugzilla.gnome.org/show_bug.cgi?id=785558