GNOME Bugzilla – Bug 533265
[cddabasesrc] Sound Juicer cut a sector when ripping a track
Last modified: 2008-05-28 15:49:07 UTC
Please describe the problem: When ripping an audio cd with Sound Juicer, you get a track that is 2352 octets shorter than the track on the cd. 2352 octets is the size of 588 audio samples, so the conclusion is that the last sector of every track is cut during the ripping. At the begining I was thinking that was the fault of Sound Juicer, but I'm wondering if it's not the gstreamer's fault because the folowing command cuts the track too : gst-launch-0.10 cdparanoiasrc device=/dev/cdrom track=1 ! decodebin ! wavenc ! filesink location=track1.wav Steps to reproduce: 1. Rip a CD using Sound Juicer or the command above and rip the same CD using the Cdparanoia binary directly. 2. Open the files of the same track in Audacity to compare the length. 3. Burn a first CD with the files ripped with Sound Juicer and a second with the files ripped with Cdparanoia. The first CD is not recognized any more on CDDB when playing with Sound Juicer whereas the second is which make me say that the problem come from Sound Juicer and not from Cdparanoia. Actual results: The files I ripped with Sound Juicer are truncated. Expected results: I would like my files not to be truncated. Does this happen every time? Yes. Other information: I filled a bug report on Launchpad : https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/210989.
<wtay> the cdda base class seems not to read the last sector, it goes EOS when curr >= track.end <wtay> and in add_track track.end must be strictly smaller than the start of the next track, suggesting the end is included in that track I think you're right and it should be eos = (cur > end). The query function also seems to include the last sector in the length: num_sectors = end_sector - start_sector + 1;
Created attachment 111664 [details] [review] Proposed patch This patch fixes some issues where the sector .end was assumed to be excluded from the track. - Fixes the check for overlapping tracks prev_last_sector >= start - Fixes the EOS condition check current > end
oh, I did not check this in because I'm not sure that all elements extending this base class assumed .end to be included in the track.
On second thought, the subclasses must do it right because we use this .end assumption in many other places. * gst-libs/gst/cdda/gstcddabasesrc.c: (gst_cdda_base_src_add_track), (gst_cdda_base_src_create): Fix EOS condition and track addition check, the track.end sector is included in the track. Fixes #533265.