Re: FLAC files produced by rhythmbox are very malformed
Nick H <[email protected]> Wed, 3 Jan 2018 12:03:56 +0000
| Newsgroups | gmane.comp.gnome.apps.rhythmbox.devel |
|---|---|
| Message-ID | <BY2PR16MB0437C9BB337848587913A082D41E0@BY2PR16MB0437.namprd16.prod.outlook.com> |
--===============0363755797586996985== Content-Language: en-CA Content-Type: multipart/alternative; boundary="_000_BY2PR16MB0437C9BB337848587913A082D41E0BY2PR16MB0437namp_" --_000_BY2PR16MB0437C9BB337848587913A082D41E0BY2PR16MB0437namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ah brilliant! Thanks for the link! ________________________________ From: Jonathan Matthew <[email protected]> Sent: November 13, 2017 6:09 PM To: Nick H Cc: [email protected] Subject: Re: [Rhythmbox-devel] FLAC files produced by rhythmbox are very ma= lformed 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 + udisk= s 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 sti= ll persists. Any track I rip within Rhythmbox produces malformed FLACs (wit= h various brand new CDs, and across different optical drives). > > > > > > Most notably is that this is a problem solely with FLAC's ripped from R= hythmbox 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 ca= nnot be updated, and therefore the files have literally no metadata in Rhyt= hmbox, nor can it be set from any program. Running flac -d on the file fail= s and produces the following error: "ERROR while decoding metadata = state =3D FLAC__STREAM_DECODER_END_OF_STREAM" and running metaf= lac from command line produces (for a random sample file) 258599 lines of w= hat looks like hexdump output. A metaflac on SoundJuicer's looks like norma= l 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 w= ell 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 tr= acks, 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 know= ing > 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 o= f any > of this means. > > You can roughly simulate the encoding pipeline used by running something = like this: > > $ gst-launch-1.0 audiotestsrc num-buffers=3D100 ! taginject tags=3D"title= =3Dtest" ! audioconvert ! audio/x-raw,channels=3D2,format=3DS16LE ! flacenc= ! filesink location=3Dtest.flac > > which produces a working flac file here. This is apparently a bug in GStreamer's flacparse element, so the above pip= eline wouldn't trigger it. GStreamer developers are discussing fixing the bug here: https://bugzilla.g= nome.org/show_bug.cgi?id=3D785558 --_000_BY2PR16MB0437C9BB337848587913A082D41E0BY2PR16MB0437namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;= color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> Ah brilliant! Thanks for the link!</div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Jonathan Matthew <= [email protected]><br> <b>Sent:</b> November 13, 2017 6:09 PM<br> <b>To:</b> Nick H<br> <b>Cc:</b> [email protected]<br> <b>Subject:</b> Re: [Rhythmbox-devel] FLAC files produced by rhythmbox are = very malformed</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">On Mon, Aug 14, 2017 at 08:20:33PM +1000, Jona= than Matthew wrote:<br> > On Sat, Aug 12, 2017 at 07:18:42PM +0000, Nick H wrote:<br> > > Hi all,<br> > > <br> > > <br> > > A few months back this bug started, while there was a huge gvfs &= #43; 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 t= he bug still persists. Any track I rip within Rhythmbox produces malformed FLACs (with various brand new CDs, and across= different optical drives).<br> > > <br> > > <br> > > 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.<br> > > <br> > > <br> > > The symptoms of the bug are fairly troubling. The metadata contai= ner cannot be updated, and therefore the files have literally no metadata i= n Rhythmbox, nor can it be set from any program. Running flac -d on the fil= e fails and produces the following error: "ERROR while decoding metadata &nb= sp; = state =3D FLAC__STREAM_DECODER_END_OF_STREAM" and running metaf= lac from command line produces (for a random sample file) 258599 lines of w= hat looks like hexdump output. A metaflac on SoundJuicer's looks like normal output but also fails to decode. If you "flac -Fd" on eit= her Rhythmbox or SoundJuicer's FLAC file and try to convert it back, it rep= orts errors as well about expected EOF's, so it looks like something's not = quite right.<br> > > <br> > > <br> > > The back-end looks like it's calling to a gnome library to rip th= ese 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.<br> > <br> > <br> > Rhythmbox and Soundjuicer use GStreamer for media encoding. With= out knowing<br> > which operating system or distribution you're using, or what versions = you're<br> > using of any of the software involved, it's hard to say what the timin= g of any<br> > of this means.<br> > <br> > You can roughly simulate the encoding pipeline used by running somethi= ng like this:<br> > <br> > $ gst-launch-1.0 audiotestsrc num-buffers=3D100 ! taginject tags=3D&qu= ot;title=3Dtest" ! audioconvert ! audio/x-raw,channels=3D2,format=3DS1= 6LE ! flacenc ! filesink location=3Dtest.flac<br> > <br> > which produces a working flac file here.<br> <br> This is apparently a bug in GStreamer's flacparse element, so the above pip= eline wouldn't trigger it.<br> <br> GStreamer developers are discussing fixing the bug here: <a href=3D"https:/= /bugzilla.gnome.org/show_bug.cgi?id=3D785558"> https://bugzilla.gnome.org/show_bug.cgi?id=3D785558</a><br> <br> </div> </span></font></div> </body> </html> --_000_BY2PR16MB0437C9BB337848587913A082D41E0BY2PR16MB0437namp_-- --===============0363755797586996985== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rhythmbox-devel mailing list [email protected] https://mail.gnome.org/mailman/listinfo/rhythmbox-devel --===============0363755797586996985==--