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

[Jonathan Matthew <jonathan d14n org>]

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.