GNOME Bugzilla – Bug 768596
Should make data tracks unrippable
Last modified: 2016-07-28 10:43:19 UTC
sound-juicer-3.20.0-1.fc24.x86_64 I put in a PlayStation CD with audio tracks (Wipeout 2097, which has one data track and 11 audio tracks), and the data track's checkbox was selected by default to be ripped. The first audio track once ripped is "this is the 2nd track of the disc".
It looks like we need to ignore tracks called [data] or [data track] at the start of the disc - https://musicbrainz.org/doc/Style/Unknown_and_untitled/Special_purpose_track_title
Created attachment 331404 [details] [review] I wonder if it should renumber the audio tracks to start at 1? Skip data tracks at the start of disc MusicBrainz ignores data tracks at the end of the disc so they never appear but those at the start of the disc (typically on PlayStation CDs) are labelled ‘[data track]’ https://musicbrainz.org/doc/Style/Unknown_and_untitled/Special_purpose_track_title
(In reply to Phillip Wood from comment #2) > Created attachment 331404 [details] [review] [review] > I wonder if it should renumber the audio tracks to start at 1? Yes, it's pretty weird that the 1st audio track is numbered as "2". > Skip data tracks at the start of disc > > MusicBrainz ignores data tracks at the end of the disc so they never > appear but those at the start of the disc (typically on PlayStation > CDs) are labelled ‘[data track]’ > > https://musicbrainz.org/doc/Style/Unknown_and_untitled/ > Special_purpose_track_title
Created attachment 331530 [details] [review] Adjust track numbers if there are data tracks Make sure the audio tracks are numbered from ‘1’ when there are data tracks at the start of the disc. Store the offset of the first audio track rather than changing the stored track numbers so the the correct track is extracted.
That didn't work as expected. With both patches applied, track 9 (Firestarter by Prodigy) ended up being ripped as "08. Underworld - Tin There (Underworld edit).mp3".
Thanks for testing it. So you tell it to extract track 9 (which is really track 10 on the disc) and it extracts the correct song but tags it with the wrong metadata? If I run ‘MUSICBRAINZ_FORCE_DISC_ID="4JY4OwbHvRoGYfG2H_ti7HjOwCM-" ./sound-juicer’ with an audio CD and select the album https://musicbrainz.org/release/a37c288d-a322-3cde-ab91-b426a309c99f from the multiple matches then extracting track 9 gets the audio from track 10 tagged as ‘Firestarter (instrumental)’ by ‘The Prodigy’ which if I’ve understood correctly is what it should do. I’m not sure what’s going wrong. I’ve just grepped the gstreamer sources for references to play station in case it did something funny when reading play station CDs but not found anything. Do you know the MusicBrainz ID of the disc you’re using?
(In reply to Phillip Wood from comment #6) > Thanks for testing it. So you tell it to extract track 9 (which is > really track 10 on the disc) and it extracts the correct song but tags > it with the wrong metadata? I made it rip all the tracks (the default selection), not a single track, so that might have an incidence. > If I run > ‘MUSICBRAINZ_FORCE_DISC_ID="4JY4OwbHvRoGYfG2H_ti7HjOwCM-" ./sound-juicer’ > with an audio CD and select the album > https://musicbrainz.org/release/a37c288d-a322-3cde-ab91-b426a309c99f > from the multiple matches then extracting track 9 gets the audio from > track 10 tagged as ‘Firestarter (instrumental)’ by ‘The Prodigy’ which > if I’ve understood correctly is what it should do. I’m not sure what’s > going wrong. I’ve just grepped the gstreamer sources for references to > play station in case it did something funny when reading play station > CDs but not found anything. Do you know the MusicBrainz ID of the disc > you’re using? Passing MUSICBRAINZ_DEBUG=1 as an envvar doesn't print out the MB ID of the release, though there's plenty of debug about unknown elements and attributes, and some 503 errors as well. Could you tell me how to get the MB ID of the disc? If you're interested, I can also make the CUE/BIN disc available to you, for use with "cdemu" as a virtual drive (I use this quite a lot for testing DVDs and VCDs, rather than needing mechanical drives).
(In reply to Bastien Nocera from comment #7) > > Passing MUSICBRAINZ_DEBUG=1 as an envvar doesn't print out the MB ID of the > release, though there's plenty of debug about unknown elements and > attributes, and some 503 errors as well. > > Could you tell me how to get the MB ID of the disc? Running tests/mb-test should print the MB ID of the albums that match the disc. git grep shows the only occurrence of MUSICBRAINZ_DEBUG is in README so that needs updating. You can set SJ_DEBUG=metadata but I'm not sure it's very useful (I've never really looked at the debugging code very closely). If you're getting 503 errors then doesn't it bail out of doing the MusicBrainz lookup and fallback to CD TEXT? Could you try using attachment 325783 [details] [review] which will retry the server and attachment 325784 [details] [review] which will avoid some unnecessary queries (the retrying can make the lookup rather slow) if you get a chance? > If you're interested, I can also make the CUE/BIN disc available to you, for > use with "cdemu" as a virtual drive (I use this quite a lot for testing DVDs > and VCDs, rather than needing mechanical drives). Thanks that would be really helpful - I'd not come across cdemu before but it sounds handy for debugging without a real disc.
(In reply to Phillip Wood from comment #8) > (In reply to Bastien Nocera from comment #7) > > > > Passing MUSICBRAINZ_DEBUG=1 as an envvar doesn't print out the MB ID of the > > release, though there's plenty of debug about unknown elements and > > attributes, and some 503 errors as well. > > > > Could you tell me how to get the MB ID of the disc? > Running tests/mb-test should print the MB ID of the albums that match the > disc. git grep shows the only occurrence of MUSICBRAINZ_DEBUG is in README > so that needs updating. You can set SJ_DEBUG=metadata but I'm not sure it's > very useful (I've never really looked at the debugging code very closely). > If you're getting 503 errors then doesn't it bail out of doing the > MusicBrainz lookup and fallback to CD TEXT? Could you try using attachment > 325783 [details] [review] which will retry the server and attachment 325784 [details] [review] > [details] [review] which will avoid some unnecessary queries (the retrying > can make the lookup rather slow) if you get a chance? SJ_DEBUG=metadata sound-juicer doesn't dump the MB release ID either. > > If you're interested, I can also make the CUE/BIN disc available to you, for > > use with "cdemu" as a virtual drive (I use this quite a lot for testing DVDs > > and VCDs, rather than needing mechanical drives). > Thanks that would be really helpful - I'd not come across cdemu before but > it sounds handy for debugging without a real disc. After downloading: https://people.gnome.org/~hadess/bug768596.bin https://people.gnome.org/~hadess/bug768596.toc You'd run: cdemu load 0 bug768596.toc And (for me at least), sound-juicer magically popped up. If you use Fedora, there's a COPR for cdemu: https://copr.fedorainfracloud.org/coprs/rok/cdemu/ Let me know if you have any trouble getting the file, or getting cdemu working. It's probably easier if I let you drain that problem which you should be able to reproduce locally.
(In reply to Bastien Nocera from comment #9) > (In reply to Phillip Wood from comment #8) > > (In reply to Bastien Nocera from comment #7) > After downloading: > https://people.gnome.org/~hadess/bug768596.bin > https://people.gnome.org/~hadess/bug768596.toc > > You'd run: > cdemu load 0 bug768596.toc > > And (for me at least), sound-juicer magically popped up. If you use Fedora, > there's a COPR for cdemu: > https://copr.fedorainfracloud.org/coprs/rok/cdemu/ > > Let me know if you have any trouble getting the file, or getting cdemu > working. It's probably easier if I let you drain that problem which you > should be able to reproduce locally. Thanks I've just set the files to download I'll let you know if I have any problems.
Created attachment 332206 [details] [review] So it looks like GStreamer automatically skips the data track so we don’t need to worry about storing the offset. Thanks for the tip about cdemu and the disc data, it makes debugging much simpler. Skip data tracks at the start of disc MusicBrainz ignores data tracks at the end of the disc so they never appear but those at the start of the disc (typically on PlayStation CDs) are labelled ‘[data track]’¹. Adjust the track numbers so that they start at ‘1’ so they make sense and also GStreamer automatically skips the data tracks so this ensures the correct tracks are played/extracted. ¹ https://musicbrainz.org/doc/Style/Unknown_and_untitled/Special_purpose_track_title
Worked great for me! You might want to re-word the last paragraph of the commit message ("so that", "so they") though. Thanks.
That’s great, thanks for testing it. I reworded the commit message before pushing it. I just tested it with an invalid MusicBrainz ID to force the gvfs backend to be used and it only shows the audio tracks so we don’t need to do anything there.