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

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:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]