Open ferk6a opened 6 years ago
rocky
commented
6 years ago I'm not going to have time to look at this. Perhaps @enzo1982 @eshattow or someone else does.
If cdparanoa works a wild guess is that one of the options that was added more recently broke this (although it fixed whatever else it was addressing). So you could try with one of the older releases or better use git bisect to find the problem.
ferk6a
commented
6 years ago So, I tried git bisecting for a bit, but then I thought that I should've just started from the earliest "compilable" commit, and I did, this is the earliest I got it to compile:
$ git checkout cf815f0
$ autoreconf -i && ./configure && make
$ ./src/cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1 /tmp/tmpnr8qzc.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 9.8 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>
Report bugs to bug-libcdio@gnu.org
Ripping from sector 1 (track 1 [0:00.00])
to sector 20654 (track 2 [0:00.-1])
outputting to /tmp/tmpnr8qzc.track01.offset667.whipper.wav
##: 0 [read] @ 21168
(== PROGRESS == [> | ...... 00 ] == :^D . ==) ##: 0 [read] @ 50568
(== PROGRESS == [> | ...... 00 ] == :^D o ==) ##: 0 [read] @ 79968
(== PROGRESS == [> | ...... 00 ] == :^D 0 ==) ##: 0 [read] @ 109368
##: 0 [read] @ 138768
(== PROGRESS == [> | ...... 00 ] == :^D O ==) ^CAnd the same -1 nonsense appears (the sector number is different because I tried out another disk).
But yes, this still works on Xiph's:
$ cdparanoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1 /tmp/tmpnr8qzc.track01.offset667.whipper.wavSending all callbacks to stderr for wrapper script
cdparanoia III release 10.2 (September 11, 2008)
Ripping from sector 1 (track 1 [0:00.00])
to sector 20654 (track 1 [4:35.28])
outputting to /tmp/tmpnr8qzc.track01.offset667.whipper.wav
##: 0 [read] @ 25872
(== PROGRESS == [> | ...... 00 ] == :^D . ==) ##: 0 [read] @ 57624
(== PROGRESS == [> | ...... 00 ] == :^D o ==) ##: 0 [read] @ 89376
(== PROGRESS == [> | ...... 00 ] == :^D 0 ==) ##: 0 [read] @ 121128
(== PROGRESS == [> | ...... 00 ] == :^D O ==) ##: 0 [read] @ 152880
(== PROGRESS == [> | ...... 00 ] == :^D 0 ==) ##: 0 [read] @ 184632
##: 0 [read] @ 216384
(== PROGRESS == [> | ...... 00 ] == :^D o ==) ##: 0 [read] @ 248136
(== PROGRESS == [> | ...... 00 ] == :^D . ==) ^COk - this is useful information. Notice that in the earlier libcdio version you are not getting the message "Time/sector offset goes beyond end of specified track."
I'm not happy about the fact that the error message doesn't indicate what the time/sector offset is nor where the end of the specified track is, but I guess we'll work with that for now.
Rethinking things more carefully, I kind of see how this might happen.
cdparanoia is Linux specific in its I/O while libcdio isn't. So probably at the I/O level libcdio in the earlier version we are getting different results. In the later libcdio version it probably correctly says that the sample offset is not valid and then refuses to read it.
If you give a different offset that libcdio thinks is valid does this work?
Fixing this may be difficult if the problem is drive specific.
ferk6a
commented
6 years ago Actually, I'm not getting Time/sector offset goes beyond end of specified track because I didn't include the case with 1[00:00:00.00]-1[00:03:13.44], but it also does that in the older version.
Regarding the offset, yes, giving no offset or some other (specific) offsets does work, the program isn't completely broken in this regard. Just that when giving this particular offset (which happens to be the correct one) it breaks and so does some other ones, which I will need to run more lengthy tests to enumerate.
But yea, it does seem to be a bit "driver specific", although on the other thread several different models were affected, but as far as I see, all of them work with a big offset such as this one (+667).
rocky
commented
6 years ago Ok, thanks. If you are up to it, would you change that error messge to include what it expected and what was seen instead? That too might point to clues.
ferk6a
commented
6 years ago Yep, I changed it. An offset that works:
$ ./cd-paranoia --stderr-progress --sample-offset 21 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>
(C) 2014 Robert Kausch <robert.kausch@freac.org>
Report bugs to bug-libcdio@gnu.org
d == -428728400
ret == 0
cdda_sector_gettrack(d, ret) == 1
i_track == 1
d == -428728400
ret == 14519
cdda_sector_gettrack(d, ret) == 1
i_track == 1
Ripping from sector 0 (track 1 [0:00.00])
to sector 14519 (track 1 [3:13.44])
outputting to /tmp/tmpoEuyVd.track01.offset667.whipper.wavAnd one that doesn't:
$ ./cd-paranoia --stderr-progress --sample-offset 667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>
(C) 2014 Robert Kausch <robert.kausch@freac.org>
Report bugs to bug-libcdio@gnu.org
d == -1684971600
ret == 1
cdda_sector_gettrack(d, ret) == 1
i_track == 1
d == -1684971600
ret == 14520
cdda_sector_gettrack(d, ret) == 2
i_track == 1
Time/sector offset goes beyond end of specified track.These lines added:
if (minutes != -1) ret += minutes*CDIO_CD_FRAMES_PER_MIN;
if (hours != -1) ret += hours *60*CDIO_CD_FRAMES_PER_MIN;
+ report("d == %d", d);
+ report("ret == %d", ret);
+ report("cdda_sector_gettrack(d, ret) == %d", cdda_sector_gettrack(d, ret));
+ report("i_track == %d", i_track);
/* We don't want to outside of the track; if it's relative, that's OK... */
if( i_track != CDIO_INVALID_TRACK ){
if (cdda_sector_gettrack(d,ret) != i_track) {
report("Time/sector offset goes beyond end of specified track.");
exit(1);
}
}
JoeLametta
commented
6 years ago @fer22f Hi, what happens if you repeat the test with the following offsets? (587, 588, 589)
A frame/sector in a CD-DA is made of 588 pairs of left and right samples. The error may be related to this (arbitrary guess), in that case those would be the expected results:
Cheers, Joe
ferk6a
commented
6 years ago @JoeLametta Just tried it out, it works exactly as you described.
Baseline: ./cd-paranoia --stderr-progress --sample-offset {offset} --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
CD: Gorillaz - The Singles Collection 2001–2011 (the first track length is relevant to the discussion, switching CDs leads to the same error when specifying the correct track length)
d == -1442922576
ret == 0
cdda_sector_gettrack(d, ret) == 1
i_track == 1
d == -1442922576
ret == 14519
cdda_sector_gettrack(d, ret) == 1
i_track == 1
Ripping from sector 0 (track 1 [0:00.00])
to sector 14519 (track 1 [3:13.44])d == 508481456
ret == 1
cdda_sector_gettrack(d, ret) == 1
i_track == 1
d == 508481456
ret == 14520
cdda_sector_gettrack(d, ret) == 2
i_track == 1
Time/sector offset goes beyond end of specified track.d == -141733968
ret == 1
cdda_sector_gettrack(d, ret) == 1
i_track == 1
d == -141733968
ret == 14520
cdda_sector_gettrack(d, ret) == 2
i_track == 1
Time/sector offset goes beyond end of specified track.Ok. I'm lost. What does this tell us - that the two bugs are the same? Does this suggest how to fix the problem?
JoeLametta
commented
6 years ago Ok. I'm lost. What does this tell us - that the two bugs are the same? Does this suggest how to fix the problem?
Unfortunately I'm not sure either: maybe that the offset of the drive isn't taken into consideration when determining the track layout (sectors it spans).
JoeLametta
commented
6 years ago @rocky Something strange happens with CDs having 99 tracks: https://github.com/JoeLametta/whipper/issues/302. Same error message too.
rocky
commented
5 years ago Here's a rough idea of what I think is going on. A CD can hold at most 99 tracks
If this jitter thing access outside of that then that can cause an error. So probably we need a test here.
I don't think I will get to this anytime soon, but I am hoping someone else will.
klslz
commented
5 years ago Not sure if I ran into the same issue.
My Lite-On drive needs a correction of "+6" . That works fine. I then tried "-24" to cope with the 30 samples offset-issue of Accurate Rip.
Basically all tracks of a CD ended up at 140 bytes and only the last one was completed.
With the standard cdparanoia all is fine.
Do you guys think this is related somehow?
eshattow
commented
5 years ago Slightly off-topic: Since 30 samples offset-issue of Accurate Rip is a problem with implementation of software other than libcdio, you may try Python Audio Tools to run verification with a wider window of computation. The most important metric is to detect an audible error in extraction and the first or last samples are almost certainly not perceptible; also as you might be concerned about is the value of automation to do this verification compatible with most other implementations. Python Audio Tools can verify AR1 and AR2 signatures within a window that matches the range of what most optical drives' offset values could be. Note I packaged Python Audio Tools for Debian and while the author was active initially I have not heard from them in some years. If you or someone you may know has interest in refining Python Audio Tools please keep me informed so I may update the Debian packaging.
Back to topic: I too had some troubles with libcdio-based extraction compared to what is widely in use (dbPowerAmp). The algorithm itself (at least AR1) does ignore these very first and very last samples. For me it does not matter but perhaps there is a usability bug that the output is not the same as i.e. dbPowerAmp; however we're not likely to want integration with software-as-a-service Accurate Rip as part of libcdio so the issue of submitting IDs to the database is moot. What does it matter if the offset is slightly off other than compatibility with proprietary software? There may be a technical discussion here about trying to get over-read and under-read to work as closely to correct as possible but it is not directly related to Accurate Rip.
On Tue, Jun 11, 2019 at 10:01 AM soundcheck notifications@github.com wrote:
Not sure if I ran into the same issue.
My Lite-On drive needs a correction of "+6" . That works fine. I then tried "-24" to cope with the 30 samples offset-issue of Accurate Rip.
Basically all tracks of a CD ended up at 140 bytes and only the last one was completed.
With the standard cdparanoia all is fine.
Do you guys think this is related somehow?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rocky/libcdio-paranoia/issues/14?email_source=notifications&email_token=AC5GJDQDJS3JSQFYUSORJYTPZ7K6RA5CNFSM4FISVCH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN2KRA#issuecomment-500933956, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5GJDS5B7XP4CCLZANJDQ3PZ7K6RANCNFSM4FISVCHQ .
JoeLametta
commented
4 years ago @rocky @enzo1982 Hi, is there any progress/update on this issue?
rocky
commented
4 years ago Not that I am aware of. Hey, this is open source so anyone can play - are you interested in investigating and fixing?
JoeLametta
commented
4 years ago I'm interested in investigating and fixing it (whipper relies heavily on cdparanoia) but I'm quite time starved and not particularly confident both with C programming and libcdio's codebase. To debug this I'd start comparing libcdio's implementation of cdparanoia with xiph's one (which seems unaffected by this bug): do you think this is a good idea?
rocky
commented
4 years ago If you are comparing using a debugger at run-time, or adding debug output (or turning some on), it probably could be done.
Comparing the source level though may be hard because there have been a number of changes that folks wanted and cdparanoia's programming style is a bit unlike any other that I've seend except in obfiscated minimized C code contests. As a result, comparing at the source-code level there will be many inconsequential or purely style changes.
If you lead the way in debugging and bug detection, I may be able to help.
MerlijnWajer
commented
4 years ago If someone has a 667 drive, maybe try this patch. It makes parse_offset aware of the passed sample_offset. I have no clue if it's the right way to deal with this.
(Apply with git am 0001-HACK-for-parse_offset-honour-sample_offset.patch)
It's not entirely correct (587 should probably be 588), but I am interested to know if it breaks accuraterip output, or ripping of the last track on drives that support overread.
cc @JoeLametta
rocky
commented
4 years ago @MerlijnWajer - Thanks for undertaking this.
You also might get help if you also mention this on the libcdio-devel mailing list https://lists.gnu.org/mailman/listinfo/libcdio-devel
fenugrec
commented
4 years ago @MerlijnWajer , I tried you patch against 55e6604 , I have a +667 drive (LG GSA-H62N). Also tested mtdcr's patch (https://github.com/whipper-team/whipper/issues/234#issuecomment-393637392)
Results: [EDITED 2019/12/30]
######### first, "reference" run with xiph cdparanoia:
$> cdparanoia --sample-offset=667 1 asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 1 [4:52.59])
... CRC: 5C9D3CA9
########### run with unpatched libcdio-paranoia
$> cd-paranoia --sample-offset=667 1 asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 2 [0:00.-1])
... CRC: 5C9D3CA9
$> cd-paranoia --sample-offset=667 1[0:00.00]-1[4:52.59] asdf.wav
Time/sector offset goes beyond end of specified track.
(does not rip)
########### run with your patch, but 588 instead of 587
$> cd-paranoia 1 asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 1 [4:52.59])
... CRC: F8E1BDC4 (mismatch due to 0 offset, that's OK)
$> cd-paranoia -O 667 1 asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 2 [0:00.-1])
... CRC: 5C9D3CA9 (matches xiph_667)
$> cd-paranoia -O 667 1[0:00.00]-1[4:52.59] asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21959 (track 1 [4:52.58])
... file is 2352 bytes (588*4) shorter, common contents identical
########### run with mtdcr patch
$> cd-paranoia -O 667 1 asdf.wav
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 2 [0:00.-1])
... CRC: 5C9D3CA9 (matches xiph_667)
$> cd-paranoia -O 667 1[0:00.00]-1[4:52.59] asdf.wav
Time/sector offset goes beyond end of specified track.
Ripping from sector 1 (track 1 [0:00.00])
to sector 21960 (track 2 [0:00.-1])
... CRC: 5C9D3CA9 (matches xiph_667)Thank you for trying - can you explain what exactly the behaviour is that you're seeing? It looks different to me, but maybe the new effect is the same. Does it rip the tracks? Do they have different checksums? What if you rip all the tracks with the offset?
fenugrec
commented
4 years ago So in my case, I'm here because of the whipper frontend ( https://github.com/whipper-team/whipper/issues/234 ) . cd-paranoia on its own seems to be able to rip the tracks (although with a few bytes different every time, but that's a seperate issue with my drive/media). But the reported bounds throw off whipper ; as I understand [EDIT : I understood wrong, this is not the case] it subtracts the two timecodes to determine the track length, so the '-1' breaks that and whipper fails to rip.
rocky
commented
4 years ago @fenugrec I am okay with extending the libcdio-paranoia behavior is to something that is more helpful to whipper, if it is the case that important lost information is happening inside libcdio-paranoia (as opposed to whipper interpreting the existing data reported back in a better way).
It is kinder to existing applications to extend libcdio-paranoia than change the current behavior, unless the current behavior has a bug that is unfixable in its current state.
fenugrec
commented
4 years ago Hi, @rocky , I think the issue boils down to two things : [EDITED ! sorry]
Time/sector offset goes beyond end of specified track". To (hopefully) explain this one better :
### expected bounds : [0:00.00] to [4:52.59]
cd-paranoia --sample-offset=588 1[00:00:00.00]-1[00:04:52.59] asdf.wav => fails
cd-paranoia --sample-offset=588 1[00:00:00.00]-1[00:04:52.58] asdf.wav => works, because I tweaked the span end.
This last one would result in an incomplete fileWhether or not current behaviour is acceptable is debatable; some arguments :
No idea if other existing apps expect different behaviour, and that would be a valid point for your consideration. I'm really not informed enough to say more about this. But I do have a "+667" drive and am willing to test patches. No time to get deep into the issue though, sorry...
MerlijnWajer
commented
4 years ago @fenugrec - AFAIU there is more going on than the bounds throwing off whipper. They throw off cd-paranoia itself too. It will not rip the track, if I recall correctly. And issues also occur when trying to rip the last track (of a 99-track CD). I will need a bit more time to take a look at this (have other things going on right now), but can probably take a look in a few days. Good to know that you have a drive with +667 offset. (Which one?)
EDIT: I just saw your edit that mentions that cd-paranoia will refuse to rip. This corresponds to what I was seeing, and it's what I was trying to fix with my patch.
MerlijnWajer
commented
4 years ago So, if the patch works the way I intended it to:
1[00:00:00.00]-1[00:04:52.59 bounds, and should instead rip.If (2) is true, then the next step is to check if it reads the right data.
fenugrec
commented
4 years ago Hi @MerlijnWajer , thanks for looking at this btw. My drive is a bottom-of-the-barrel LG / HL-DT-ST GSA-H62N.
I thought it would be better to have only one version of that set of results so I edited that post again. Added CRCs for comparison.
Also added results for another patch (mtdcr) that just removes the exit(1) statements hit when offsets >= 588, thereby forcing to proceed with the rip. Results are interesting.
Apologies if it's hard to follow my tests, I have a confusing setup with 4 different versions of cd-paranoia !
Regarding your patch:
MerlijnWajer
commented
4 years ago Hm, so the patch does seem to do the right thing, but it doesn't rip as much as it should, that should be fixable. I am not sure just removing the exit(1) calls in the right solution. Thanks for testing. I don't have time right now to take a look, but will try to find some time soon.
TheMuso
commented
4 years ago I have been spending some time looking at some of the code in src/cd-paranoia.c, and lib/cdda_interface/toc.c. So far as I can tell, the use of toc data in the cdrom_drive_t->disc_toc data structure/array causes problems whenever cd-paranoia modifies the disc_toc[]->dwStartSector value for audio tracks as needed for sample offset correction that is 1 sector or more, i.e 589 samples or more.
Most functions in lib/cdda_interface/toc.c work directly with the cdrom_drive_t->disc_toc array/struct, which is fine. However calling cdio_cddap_sector_gettrack() calls cdio_get_track(), which in turn works with the underlying CD driver to return the appropriate track number for the given LSN. This does not take the adjusted data in cdrom_drive_t->disc_toc->dwStartSector into account.
Even then, other functions that do work with cdrom_drive_t->disc_toc have conditions that assume the first sector of the first track on the disc starts at 0, which normally it would, unless offset correction has been applied.
Consider cd-paranoia, run in batch mode, with a sample offset set to 667 samples. Through some calculations, found in src/cd-paranoia.c at lines 1113-1120, toc_offset is set to 1, as 667 samples is 1 sector, (588 samples) + 79 samples. The contents of toc_offset are added to all the track start sectors, stored in d->disc_toc[], aka cdrom_drive_t->TOC_t, in lines 1126-1130.
In src/cd-paranoia.c, line 1187, we have:
i_first_lsn = cdda_disc_firstsector(d);
The cdda_disc_firstsector() function finds the first audio track on the disc, and if the first audio track on the disc is the first track, then 0 is returned. If it is not the first track, then the start sector for the given track is returned, and the returned value is previously adjusted with the value from toc_offset, as pointed to above. Similar inconsistancy is found in lib/cdda_interface/toc.c, in the cdda_track_lastsector() function. The adjusted TOC data is used, only in some circumstances.
I have a partially completed solution here, which takes relevant functions from libcdio_cdda, and modifies them to fully take adjusted TOC offset data into account. What I have done so far has been tested and works, although i still need to make sure overreading works. I do wonder whether the better solution is to extend libcdio_cdda to adjust LSn values on the fly, according to a given TOC offset, and whether force overread is requested. If @Rocky prefers the cd-paranoia executable be modified, then I am ok with that, in which case I will finish working on my patch, and post it here for testing and consideration.
My testing involves the use of a PIONEER BD-RW BDR-XD05, which requires a read offset correction of +667 samples. This drive it turns out, is pretty good, in that it can overread into the lead-out. I have verified this, by firstly using Exact Audio Copy in Windows to create an EAC test audio CD, which helped me check whether overread into lead-out was supported, and also work out the drive's write offset correction, which turns out to be 0. I then created a test CD, with the last track containing audio at the very end of the track. I then verified the drive could read into the lead-out, by ripping the last track with EAC, and compared the raw audio ripped from the disc with the original I created. I Verified the files matched using sha256 checksums. Yes, this is not the best way to check, and I know there are likely better ways of verification, but the sha256 checksums matched. This is of course with no wav or other file format header, just raw PCM 16-bit signed little-endian audio data.
I hope this all makes sense, and feel free to ask for clarrification if you are not sure about something I have talked about above.
rocky
commented
4 years ago @TheMuso First and foremost thanks for looking into this. If you think the better place to fix is in libcdio_cdda and are willing to work on that is great. If that is to be done, I can put out a release with the better and extended interface.
It may take a while however for a change like this in libcdio to get adopted in "downstream" distiibutions because each distribution has other packages that have dependencies on libcdio which would also need to be updated, and each distribution has its own release schedule. https://repology.org/project/libcdio/versions has a list where things are currently at.
Therefore what was done in the past in situations like this, notably with thie CD-Text fixups, is to have some sort of compatibility mode where a change would be done both here and in libcdio and a test on the API version number is made for which code to use. By the way, that is also probably the easier route to develop and test.
Currently, at configure time, libcdio checks for libcdio >= 0.8.3 which seems wrong. I imagine at least some form of 2.x is now needed. I'll change that soon.
To test the API inside a C program use LIBCDIO_VERSION_NUM which currently has a value 20100 (for 2.1.0 == 2.0 + 1.0 + 0 although it could also be 2.0 + 1 + 00) .
libcdio and cd-paranoia should follow semantic versioning and so I imagine this change to libcdio's API would mean a 2.2 release.
Since you are doing the most of the work, I leave to you which route to go. I am okay with either and can do the releases either way.
As for the technical details of what is wrong, considering the history, the bug is perfectly natural.
I'll explain next but feel free it skip this if it is not of interest.
git-blame indicates the code you mention goes back to the original cdparanoia where drive reading code and the paranoia skip and jitter detection were all rolled into one package that was targeted for GNU/Linux only.
Some time later, the TOC reading problems and problems with CD's with multiple sessions was noticed and meticuloulsy fixed by Thomas Schmitt, hence the version bumps in libcdio.
We didn't consider back then that the paranoia library would also have bugs nor would need to be fixed. I am sure I wasn't all that aware of drive overread problems having read in that comment cited before, which is really from Monty the primary and original author, and more importantly guy who knows more about this stuff than I do.
JoeLametta
commented
4 years ago @TheMuso Hi, is there any progress about this issue?
TheMuso
commented
4 years ago On Thu, Sep 10, 2020 at 06:22:33PM AEST, JoeLametta wrote:
@TheMuso Hi, is there any progress about this issue?
Sorry, Other things have gotten in the way since I looked into this. I will try and make some time in the next couple of weekends or so to work on the fix.
Luke
JoeLametta
commented
4 years ago Sorry, Other things have gotten in the way since I looked into this. I will try and make some time in the next couple of weekends or so to work on the fix.
Luke
Thanks for the status update: didn't intend to put pressure on you :wink:
JoeLametta
commented
3 years ago @TheMuso Kindly asking again for a status update, thanks!
TheMuso
commented
3 years ago I'm sorry, I mentally made a note to reply to this, and forgot.
Not sure when I'll have the time to work on this. Someone is welcome to work on it if they wish.
45054
commented
3 years ago Hi. I have put a small bounty on this bug: https://www.bountysource.com/issues/60536098-incorrectly-fetches-track-length-with-certain-offsets for anyone interested in solving this.
samliddicott
commented
3 years ago I added $15 to that, so it stands at $115
I don't know when I'll have time to try whipper again but I'd like it to when when I next have got time
Sam
On Fri, 14 May 2021 at 12:20, 45054 @.***> wrote:
Hi. I have put a small bounty on this bug: https://www.bountysource.com/issues/60536098-incorrectly-fetches-track-length-with-certain-offsets for anyone interested in solving this.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rocky/libcdio-paranoia/issues/14#issuecomment-841182267, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABL7PTHFKLB3VONNAC4DKLTTNUBOPANCNFSM4FISVCHQ .
seisure
commented
3 years ago I'm sorry, I mentally made a note to reply to this, and forgot. Not sure when I'll have the time to work on this. Someone is welcome to work on it if they wish.
As far as I have understood you've made already good progress. Wouldn't it make sense for others to build upon your work? Can you make your branch available? Thank you.
returntoreality
commented
2 years ago I've added another $50 so it stands at $165
45054
commented
2 years ago Although the Bountysource currently states 165$ I have to add that my bounty of 100$ has expired and was paid back after some mail exchange (the automatic process does not work apparently).
Anyone fixing the bug will still get the 100$, we will find a way. Bountysource however does not appear to be very reliable anymore (see https://github.com/bountysource/core/issues/1539)
dangpzanco
commented
2 years ago Any update on this issue?
rocky
commented
2 years ago It looks like there isn't anyone interested on working on this even for the bounty listed above. But, hey, this is open source code so anyone can dive in and fix. Hey, how about you?
dangpzanco
commented
2 years ago @rocky yup, I'll probably try implementing the suggestions @TheMuso gave. The problem is I only discovered this project this week (via whipper's pinned issue) and I'm not very familiar with the concept of offset on CD drives.
fenugrec
commented
2 years ago Interestingly just last week I was (trying to) rip some CDs for the first time since I last posted earlier up, ran into the same issue again, and remembered this ticket. I still have that drive and could find time to try patches, but no time for any coding.
rocky
commented
2 years ago I'm not very familiar with the concept of offset on CD drives.
No one is born being familiar with the concept of offset on CD drives. But as Richard Feynman has said: "What one fool can learn, so can another".
francoisjacques
commented
1 year ago I think the challenge here lies into understand:
Perhaps if someone could come up with a C snippet that would demonstrate the incorrect output for a given set of inputs as test case, it would make the journey a little simpler. If the issue is only reproable with a physical reader, it makes the troubleshooting much more difficult...
In my professional life, I often had to do such archeological work (what did the original developer intended? Can I make the original code work with a modern compiler and use that as reference?) and incrementally study the drift in time to understand what the later changes did. Of course, it depends how much time someone is willing to invest to fix such issue.
If it was easy to fix, it'd be already fixed...
fenugrec
commented
1 year ago Perhaps if someone could come up with a C snippet that would demonstrate the incorrect output for a given set of inputs as test case, it would make the journey a little simpler.
How about instrumenting a few key API calls and logging arguments and return values ? Probably more useful than an strace log . Maybe 'rr' could be used as well ?
buddyabaddon
commented
8 months ago I believe I have a fix for this issue #38.
If others with different drive offsets can help test (mine is +667), I'd like to hear your results.
mdosch
commented
8 months ago I ran whipper offset find which identified an offset of 594 for my
PHILIPS - CDRW-DVD CDD5263 which is the same as at
https://www.accuraterip.com/driveoffsets.htm.
Ripping a CD also worked successfully. :+1:
I've seen a number of people running into the same issue when using whopper (https://github.com/JoeLametta/whipper/issues/234), and one user going as far as just removing errors checks in the source code to force cd-paranoia to continue working (https://github.com/JoeLametta/whipper/issues/234#issuecomment-393637392).
My hardware is HL-DT-ST GH22NS50, and in the AccurateRip database, it is expected that its read offset is +667. However, when using that number with cd-paranoia, it stops saying that the time/sector goes beyond end of my specified track:
However, Xiph's cdparanoia works ok:
And following the advice to leave out the time argument to cd-paranoia to guess, I end up with a very weird time signature indeed (but the sector number does match and the track is correctly ripped):