FLAC files produced by rhythmbox are very malformed
Nick H <[email protected]> Sat, 12 Aug 2017 19:18:42 +0000
| Newsgroups | gmane.comp.gnome.apps.rhythmbox.devel |
|---|---|
| Message-ID | <BY2PR16MB04374C9259A2ED38099DB188D48E0@BY2PR16MB0437.namprd16.prod.outlook.com> |
--===============3630736878979745484==
Content-Language: en-CA
Content-Type: multipart/alternative;
boundary="_000_BY2PR16MB04374C9259A2ED38099DB188D48E0BY2PR16MB0437namp_"
--_000_BY2PR16MB04374C9259A2ED38099DB188D48E0BY2PR16MB0437namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
A few months back this bug started, while there was a huge gvfs + udisks ch=
ange 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 p=
ersists. Any track I rip within Rhythmbox produces malformed FLACs (with va=
rious brand new CDs, and across different optical drives).
Most notably is that this is a problem solely with FLAC's ripped from Rhyth=
mbox and SoundJuicer. Cdparanoia rips wav's just fine, and those can be con=
verted 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 Rhythmbo=
x, nor can it be set from any program. Running flac -d on the file fails an=
d produces the following error: "ERROR while decoding metadata =
state =3D 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 ou=
tput but also fails to decode. If you "flac -Fd" on either Rhythmbox or Sou=
ndJuicer'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.
Thanks,
Nick
--_000_BY2PR16MB04374C9259A2ED38099DB188D48E0BY2PR16MB0437namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p>Hi all,</p>
<p><br>
</p>
<p>A few months back this bug started, while there was a huge gvfs =
3; 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 a=
cross different optical drives).</p>
<p><br>
</p>
<p>Most notably is that this is a problem solely with FLAC's ripped from Rh=
ythmbox and SoundJuicer. Cdparanoia rips wav's just fine, and tho=
se can be converted to FLACs that work just fine.</p>
<p><br>
</p>
<p>The symptoms of the bug are fairly troubling. The metadata containe=
r 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:
"<span style=3D"font-family: Calibri, Helvetica, sans-serif, EmojiFon=
t, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoj=
i, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; fo=
nt-size: 16px;">ERROR while decoding metadata </span><span style=3D"fo=
nt-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emo=
ji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol=
", "Android Emoji", EmojiSymbols; font-size: 12pt;">
state =3D F=
LAC__STREAM_DECODER_END_OF_STREAM" and </span>running metaflac fr=
om command line produces (for a random sample file) <span>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 SoundJ=
uicer's FLAC file and try to convert it back, it reports errors a=
s well about expected EOF's, so it looks like something's not quite right.<=
/span></p>
<p></p>
<div><span style=3D"font-size: 12pt;"></span></div>
<div><br>
</div>
<p></p>
<p>The back-end looks like it's calling to a gnome library to rip these tra=
cks, but I'm not too familiar with the Rhythmbox codebase to say for s=
ure. Can someone comment on how these files are produced? I'd like to see t=
his bug fixed, and am willing to help
but could use somewhere to start.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Nick</p>
</div>
</body>
</html>
--_000_BY2PR16MB04374C9259A2ED38099DB188D48E0BY2PR16MB0437namp_--
--===============3630736878979745484==
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
--===============3630736878979745484==--