PDA

View Full Version : dbpoweramp says drive cannot read into lead out; different results with it on



mirror-image
03-06-2008, 01:50 AM
Hi,

I have read up everything I can find on offsets and reading into lead-in and lead-out and how to check whether my drive supports it.

EAC says the drive does.
dbpoweramp does not complain unless I ask for the pop up log. When I get that log and have it turned on, it says my drive cannot read into the lead-out and I must uncheck the option.

The drive is an LG-H55N. Offset is set to +102 as indicated by AccurateRip. If I am correct, this means lead-in reading is not necessary.

AccurateRip gets a confirmation for either rip, as expected, because as I understand it it is checking up to just before the last few samples to compensate for drives which cannot read the lead-out.

but using Beyond Compare I can see a difference in the files for the last track. I have compared several cds this way and this is the first to show this result on the last track.

In the rip with read into lead-in or lead-out *off*, I see only zeros after a certain point.

The rip with the option *on* shows small amounts of data right up to the end of the file.

The files are byte-size identical, which leads me to believe the first (non-lead-out) version has been padded with zeros to be the correct size.

Am I correct that dbpoweramp has made a mistake, this drive *can* read into the lead-out (and has done so, but for some reason dbpoweramp thinks it did not,) and the rip with the lead-out set to on is the correct rip?

Or am I wrong, and that data is garbage from trying to read into the lead-out on a drive which cannot do it? If this is the case, why not on more discs?

Is there potential for ripping problems with dbpoweramp if this option is enabled and the drive cannot do it? I would prefer to leave it on if there will be the occasional disc losing end of track data on the last track without it.

I suspect the other discs do not have any data in the lead out, which is why they match completely (they are also byte-size identical whether the option is on or off, but they are also 100% content identical.)

Thanks in advance.

mirror-image
03-06-2008, 02:11 AM
I thought this might help. Here's an image capture showing the additional data from Beyond Compare.

The content highlighted is the extra content which was all zeros in the file which was ripped with 'read lead-out' set to *off*.

http://img297.imageshack.us/img297/8234/beautifulcomparevd8.jpg (http://img297.imageshack.us/)

As you can see, it is very consistent with the data that came before. Which leads me to suspect even more strongly that the drive is delivering the correct data for those samples when 'read lead-out' is set to *on*, and dbpoweramp is padding with zeros if it is said to *off*.

In addition, I ripped the track another 2 times with 'read lead-out' set to *on* and compared all the files. They were identical each time, all having the same CRC in dbpoweramp, and the same additional data. I don't know if this means anything. It might be that the same garbage data is being returned each time.

Spoon
03-06-2008, 04:35 AM
If lead out reading is unchecked the program will not attempt and fill with 0's
If it is checked and the drive cannot read (as shown by the log), the program retries and scales back into the normal cd area, zeros are added to teh end.

So both methods (if you see '** Drive is unable to read into lead out, uncheck over-read option.') will give zeros on the end.

mirror-image
03-06-2008, 06:22 AM
Thanks for the reply.

Okay, so there is no problem having it checked if the drive does not actually support it (I don't know how to find out for sure, since dbpoweramp and EAC disagree on this.) If it is not supported I get the same output as if it was off, if it is.

But this file is definitely not padded with zeros despite the log report saying over-read into lead-out not supported.

The other file, instead of a few lines of data, has a single line which is very long and contains the same number of "characters" (I know this is binary data really) which are all zero samples.

http://img148.imageshack.us/img148/2740/zerosla4.jpg (http://imageshack.us)

the line is much longer than that, it's just all that fitted in the window.

There are zero samples at the end of this file but definitely not zero samples at the end of the one with read lead-out checked, which means they did not both fill with zeros.

The logical deduction to me is that the data was read from the lead-out.

I decided to rip the same track with EAC (which says I can read into the lead-out) with overread both on and off, and "fill with zero samples" on and off.

First the results of comparing those:

1. Rip with fill and no over-read does not match rip with no fill and no over-read - there are zeros at the end of the filled one and no data in the unfilled one. This means EAC will only fill if asked (as expected.)

2. Rip with over-read and no fill matches rip with over-read and fill (no zero samples at end in either) meaning both got the same data from the over-read and performed no filling with zero samples because there was nothing to fill. All available data was read.

3. Rip with over-read both match rip with over-read in dbpoweramp.

4. Rip with no over-read and fill matches rip with dbpoweramp and no over-read

So both programs get the same results with the same settings, with the same differences between the files.

This added to what you said about dbpoweramp always filling with zeros if it cannot get the lead-out indicates to me that it did get the lead-out, but reported that it did not. There are no padded zero samples if I turn it on, only if I leave it off.

Thanks for your reply. I might not have thought to check EAC if I hadn't learned how dbpoweramp handles these situations, and the two results compared has convinced me that over-read should be on despite dbpoweramp claiming it should not.

My other drive does not support over-read, but if I get a chance I will try these rips on another that does and see if I get the same data again.

Now to get into my cd collection :)

Spoon
03-06-2008, 07:18 AM
We will be doing work in this area in the next 4 weeks, I am going to set a robot autoloader with a Plextor which cna overread to find some discs in my collection which have samples right to the end.

pls1
03-13-2008, 09:49 PM
I believe I have run across this with some Deutsche Grammophone repackaged box sets. When you determine some tests or have some test code, I would like to evaluate those discs with whatever you come up with.

Phil

pls1
03-15-2008, 08:50 PM
I've run accross this inconsistency on about six Deutsche Grammophone discs so far (Jochum and Karajan Bruckner boxed sets and Levine-Bartok).


The last track will not give a consistent Checksum across drive models but the check sums are the same for all previous tracks.
The last track gives different Checksums for drives that dbpoweramp says cannot read into the lead in and lead out when read into lead in or lead out is toggled.
All drive models give a self consistent checksum across multiple instances of the same model drive on multiple re-rips with the same lead-in/out setting
All drives are set for secure ripping and quit with the same number of ultra passes passes and no frame re-rips
All of these discs are short total time so there is a band on the outside of the disc that has not been used
There is no visible damage looking through a magnifier.
All drives were tested with a different disc in accurate rip before and afterthis test to make sure the drive and dbpoweramp were working correctly

There are a total of TEN DIFFERENT check sums across five drive models which were:

PX-230
B900A
PX755/760
Plexwriter Premium
Samsung 183

Phil

Spoon
03-16-2008, 03:32 AM
Does the PX755 read into lead out?

pls1
03-16-2008, 11:20 AM
Yes as far as I know.

The 755 and the 760 model drives give the same check sums consistently for lead/out toggled on and off. However, the checksums are different for "read into lead in/out" on vs. off. These drives seem to have the same chipset.

The 755 and 760 drives are on two different computers. Those matching checksums between the models 755 and 760 are the only case where the different drive models give the same check sums on the last track of these discs.

Phil

Spoon
03-17-2008, 04:33 AM
The premium, 755 and 760 should all give the same result as they even have the same offset.

pls1
03-17-2008, 07:34 AM
I re ripped the last track with Plextor premium since I could have labeled the logs backwards.

With read into lead in lead out =NO the 755, 760 and Premium give the same same checksum

With read into lead in lead out = YES the 755 and 760 give the same value but the premium gives a different check sum.

All results were: Secure [Pass 1, Ultra 1 to 1]

phil

pls1
03-17-2008, 09:05 PM
Found another one and the CD is a 1992 Harmonia Mundi not repackaged DG like the others

This was a clean rip on all three drive models 230/755/B900. Only the last track is a mismatch but the last track gives six different checksums across the three drives toggling leadin/out. The second to last track gives six identical Checksums.


Phil

Spoon
03-18-2008, 04:07 AM
The 230a cannot overread for sure, your testing should be limited to drives which are known to overread: Premium, 755, 760.

pls1
03-18-2008, 08:32 AM
OK so what does it mean to get the different checksums with "read into lead out" OFF across the four drives?

Phil

pls1
03-18-2008, 11:56 AM
Plus if you are working on this as a "known bug" it doesn't have to be a high priority item just on my account. I'm putting these in my re-handle pile along with discs too damaged to rip.

I have at least 3500 plus CDs to go. I just want guidance on expectations.

Phil

tourrilhes
03-18-2008, 01:36 PM
OK so what does it mean to get the different checksums with "read into lead out" OFF across the four drives?

Phil

Hi,

I've had that a lot. Most likely it means that the 4 drives have different offsets.

Because most drive have a positive offset (i.e. the music starts after after the start of ripping), the last bit of music is lost (i.e. the rip stop before the music end). Using overread in lead out allow to rip beyond the rip end and therefore rip to the music end. Most CDs have NULL samples at that point, so it doesn't matter, a few CDs have noise, and therefore the tracks are different.

The way to check that is to use the AccurateRip CRC, not the rip CRC. Another way is to use a WAV comparator program (EAC has that buit in) and check that the track difference is indeed only at the very end. In most case, you will see that the difference occur in the last track at a time after the official end of the track from the TOC.

Note that on CDs that are full, the last track has often ripping errors, so you want to check that as well.

Good luck...

Jean

pls1
03-18-2008, 02:32 PM
OK I think understand your point but what i am not clear about is why i should get different results with two different drives that read into the lead out. Even with different offsets, if the settings are correct in dbpoweramp, i would expect the same result. The reason I first noticed this was I had a disc where all but the last track matched accurate rip. On this disc, and several others like it, I could get a match with accurate rip by changing the drive, that is either to one that does or one that doesn't read into the lead out. There are still a few like the ones I had previously referred to.

Contrary to your observations of CDs in your collection, all of the CDs I have found so far are short total lengths and not full at all.

I had put off ripping my collection because I didn't want to get into the internals of audio processing, oh well. I'm just going to mark the CDs I find and come back later when have some time to look at what is at the end of the discs with some additional software.

Thanks for the help.

Phil

Spoon
03-18-2008, 03:32 PM
The reason I first noticed this was I had a disc where all but the last track matched accurate rip.

This has nothing to do with overreading, Accurate Rip only calculates to the end - 5 frames, unless you have a drive with an offset > 5 frames (there is not one) all drives will return the same AccurateRip CRC (what happens right at the end of the CD does not matter). You are seeing a diffrent problem (of a drive which is not ripping the CD correctly).

pls1
03-18-2008, 06:02 PM
You are seeing a different problem (of a drive which is not ripping the CD correctly).

So now I'm really confused.

I've got at least two physical drives of the same drive model across four different (chipsets and offsets) drive models. Each model gives a consistent checksum that dbpoweramp says is secure and there are no frame re-rips. All the checksums are different across the drive models. All 12 instances out of about the 10,000 tracks I've ripped so far are the last track on the CD.

The logical implication of your quote is that at least four of the five models are ripping these track improperly.

What am I missing?

Phil

Spoon
03-19-2008, 04:53 AM
Yes correct, I have seen drives where the accurate stream fails mid rip (perhaps on your disc somewhere on the last track), when this happens it is as though the drive suddenly has a different offset. I have seen it myself on a certain disc a Plextor 708a & 230a.

pls1
03-19-2008, 10:04 AM
Just to be sure, because the self consistent checksums are what confused me.

1. the failure is caused by some specific artifact on the disc that all models of drives "fail" at because otherwise can't understand why eight drives across four models would "fail" to consistent to different relative offsets and hence checksums on multiple drives.

2. Can you recommend a software tool (cost isn't really important) that would allow me to easily examine this at the detail level not be a major pain to learn, as well as be a generally useful digital audio tool.

Thanks for your help,

Phil

tourrilhes
03-19-2008, 12:03 PM
Just to be sure, because the self consistent checksums are what confused me.


Don't worry, you are not the only one to be confused, I am as well.



2. Can you recommend a software tool (cost isn't really important) that would allow me to easily examine this at the detail level not be a major pain to learn, as well as be a generally useful digital audio tool.

Phil

Personally, I would start with the "Compare WAV" function in EAC. You don't need to configure EAC for that, no need to rip with EAC, you just point that tool to the two WAV tracks on your HDD and it will give you a nice diff. I use Foobar to convert from FLAC to WAV. I've used it with great success and it's really simple and quick.

dBamp may have the same function, Spoon should be able to tell you about it.

Obviously, this is not a complete analysis tool, but a good start and it's good enough for me.

Jean

pls1
03-19-2008, 03:00 PM
What bothers me is the "Secure" message from dbpoweramp but mismatching consistent CRCs accross the drive models.


This has nothing to do with overreading...,CRC (what happens right at the end of the CD does not matter). You are seeing a diffrent problem (of a drive which is not ripping the CD correctly).

After a quick test this error IS at the very end of the last track of the CD. EAC lists the timing as 4.26.25.

The mis-matching samples are listed by EAC WAV compare as at 4.26.316 to 333 to 345 depending on the drive model pairing. The dbpoweramp logs show the rip as secure and the dbpoweramp log CRCs are still different by drive model and consistent across different drives of the same model. Read into lead-in/out is definitely OFF

Plextools PRO XL reports no errors on its DAE and no C2 errors on the quality check. The Plextools WAV files from the three drives match each other but DO NOT match the dbpoweramp WAV file.. I'm out of lunch hour time so I can't compare EAC rips since I needed to install it for the compare and it is not configured.

I probably won't get back to this until Saturday but I'll bet my other 10 last track CDs will show the same pattern of differences at the very end.

Any comments???

Phil

Spoon
03-19-2008, 03:55 PM
What is the exact length of the track?

pls1
03-19-2008, 05:00 PM
The logs in dbpoweramp from the three drive models all say:
"says Ripped LBA 171405 to 191380 (4:26)"
across the three drives Px-230/755/B900 with different dbpoweramp log CRC results.

EAC says the track length is 4.26.25. Not set up for ripping, maybe tonight

All Plextools Pro XL WAV files are of identical length at 46,981,244 bytes and compare as identical with EAC WAV compare.

for DB Poweramp the WAV files are of identical length at 46,981,444, bytes but not identical when compared with EAC's WAV compare.

all three drives will match to accuraterip (confidence 3 or greater) the last track of several other CDs both before and after this test so the drives are working properly.

I'm sticking with this CD out of ten similar behaving CDs because there is absolutely no damage. It is Harmonia Mundi HMC 90389 Musique Arabo-Andalouse. Total length printed on the outside of the jewel case is 42min 2 sec. with 14 tracks. 1991

What else should I look at?
Phil

tourrilhes
03-19-2008, 07:41 PM
After a quick test this error IS at the very end of the last track of the CD. EAC lists the timing as 4.26.25.

The mis-matching samples are listed by EAC WAV compare as at 4.26.316 to 333 to 345 depending on the drive model pairing.


The error is beyond the official end of track. This is exactly what I have and I believe it's related to the offset business. Personally, I would not bother about it, as I believe it's in the silence after the music.



All Plextools Pro XL WAV files are of identical length at 46,981,244 bytes and compare as identical with EAC WAV compare.

for DB Poweramp the WAV files are of identical length at 46,981,444, bytes but not identical when compared with EAC's WAV compare.


If I understand correctly, it seems that Plextools is cutting the track to its official lenght, and therefore don't read the part where there is difference. Have you tried to compare the Plextool WAV to the dBamp WAV ?


all three drives will match to accuraterip (confidence 3 or greater) the last track of several other CDs both before and after this test so the drives are working properly.

What else should I look at?
Phil

In my case, I decided to not worry and ignore this. I mean, the difference is not within the track, it's at a point after the track where you have silence or very silent noise. I would never hear it, and I can't really care about this kind of errors. If you are worried, you may want to cut the track to its official length and discard this extra junk.

I had one case where it happened within the track itself, on my SimpleMinds CD, and Spoon blamed EAC.

Jean

pls1
03-19-2008, 09:16 PM
I'm sorry I was in a hurry to get this done so here is what I left out of my lunchtime post:

1. I had assumed in my reply to your post of yesterday that this was a known "end of disc and end of track" problem. I was just marking these discs to analyze later. It was Spoon's post indicating otherwise that caused the EAC WAV compares today.

2. The WAV compares do NOT match between Plextools and dbpoweramp but the differences are at the EOF.

3. To comment on your post of a few minutes ago at Hydrogen, the dbpoweramp WAV files are different between burst and secure on one drive.
All my discrepancies are at end of disc. I just updated my written workflow for dbpoweramp (my wife and I are sharing the 5000 CD ripping project) since I have sufficient drive diversity and QC redundancy to catch discrepancies.

However, the "Secure" message from dbpoweamp is bothersome. I guess I'll set up EAC sometime as another Q/C alternative in addition to PlexTools ProXL for my "suspect" discs.

Thank you for all of your comments here and on the other two forums. Greynol, Spoons, yourself and a some others have been indispensable in keeping me forging ahead.

I abandoned this same ripping project a few years ago because of consistency and quality problems. I'm sure I'll complete the project this time in a few months.

Phil

Spoon
03-20-2008, 08:18 AM
4.26.25

30 samples offset = (30 / 44100) = 0.0006 seconds = 4.26.2506 which is not 4.26.316 something is amiss. Hold the mouse over the file and dBpoweramp will tell the number of audio samples, is it the same for all files, what is it?

pls1
03-20-2008, 09:18 AM
4.26.25

Hold the mouse over the file and dBpoweramp will tell the number of audio samples, is it the same for all files, what is it?

The 4.6.25 is what EAC showed.

I needed to re-run these tests because the default for meta-data ID tags in dbpoweramp does not have the attribute "length" checked.

When I re-ripped all three drives show the same: "Length: 266333"

The EAC wave compare show identical file for the same drive "Secure" and "Burst"

The differences occur in the EAC WAV compares between drive models are at:
4.25.316-320 for the 900 to 230 model compare

4.26.331-343 for the 900 to 755 model compare

4.26.316-332 for the 755 to 230 model compare

Phil

pls1
03-20-2008, 05:36 PM
The differences occur in the EAC WAV compares between drive models are at:
4.25.316-220 for the 900 to 230 model compare

4.26.331-343 for the 900 to 755 model compare

4.26.316-332 for the 755 to 230 model compare


Typo in the first compare, obviously it should be
4.25.316-320

LtData
03-20-2008, 05:54 PM
There, I edited the typo, now it is correct.

pls1
03-22-2008, 11:17 AM
I did a perfunctory compare on a few of the other "last track different checksums" discs. As per EAC WAV compare, the discrepancy errors are all at the very end of the track.

Therefore, since all the drives continue to match accurate rip on popular discs, it seems from the various other posts here and at HA, that this is a known problem.

Unless Spoons has some other suggestions or requests, from my point of view, this is resolved as a known problem.

If I detect any consistent errors NOT at the very end of the track (as has been discussed here and elsewhere) I'll post them.

Thanks to everyone who contributed to my understanding of how this stuff works.

Phil

bhoar
03-22-2008, 11:42 AM
If spoon could write a concise summary of the cause of the problematic checksums related to the end of tracks on these special discs, that would be great.

-brendan

Spoon
03-22-2008, 06:01 PM
2 drives which cannot overread (with different offsets), even if the option is on or off, will always produce different CRCs on the last track.

bhoar
03-22-2008, 06:16 PM
2 drives which cannot overread (with different offsets), even if the option is on or off, will always produce different CRCs on the last track.

Ah.

Addendum: in all cases with pristine and non-defective discs, the AccurateRip will continue to match, because the last 5 frames of the last track are never included in AccurateRip calculation.

This discarding of the last 5 frames is done specifically to work around issues such as those above that can never be resolved via software.

-brendan

Porcus
03-31-2008, 06:52 PM
A maybe related problem, the Sony mediachanger, identifies as Matshita DVD-RAM SW-9584 B104, offset +102 -- dBpoweramp says it can read into lead out, but:

I ripped all with lead in/out checked, and without. Removing those without AR entry or with all tracks inaccurate (different pressings), I were down to 115 discs.

-> Burst rip, lead i/o UNchecked: 97 discs clean, 18 discs with inaccuracies, of which 6 only in the last track.

-> Ultra-secure, lead i/o ON: These 6 inaccurate last tracks have now increased to 50. That is about half of the discs.

-> Tried these 50 discs with EAC, testing only the last track with lead i/o ON: The vast majority (say, 45 of those 50) were still inaccurate. Only a few were tested with lead i/o UNchecked, all of them accurate. Did not try EAC on the remaining fifty-something to see whether EAC produces inaccurates that dBp does not.


So it seems that on this particular drive, checking lead i/o will produce Inaccurate last track in about half the discs -- regardless of application.

Oh, and there are some noteable discrepancies in the AR numbers. A couple of discs have quite a lot higher Inaccurate confidence on the last track than Accurate on the rest -- I suspect coming from re-rips with different software, setting, or CD-drive -- but also a few discs with lower number on the last track. What is, plausibly, the explanation? Among the latter are
Audioslave - s/t - 13 tracks Accurate (131 to 134), 14th track Inaccurate (38).
Tori Amos - Scarlet's Walk - 17 tracks Accurate (62 to 65), 18th track Inaccurate (15).

Porcus
04-06-2008, 05:50 AM
A maybe related problem, the Sony mediachanger, identifies as Matshita DVD-RAM SW-9584 B104, offset +102 -- dBpoweramp says it can read into lead out, but:

... but I don't think it can, I think this phenomenon is drive-dependent. Not able to reproduce it to the same extent elsewhere.

sjmac
08-17-2008, 05:23 PM
Hi,

I'm having this "missing samples" problem, tested with R13 and R13.1 - both reference versions, I think - I paid anyway ;-)

[edit:Solved my problem now; needed to click the Options button in dbPA CD Ripper (not the little arrow next to it!), choose Read in to Lead In or Lead Out option AND change the "Communication" option from Windows Internal [For Limited Accounts] to any of the other options except SCSI Pass Through Read(D8), which didn't work on my machine.

The screen grab below shows the issue. The windows on the left show a close up of two .wavs extracted using Exact Audio Copy from CD on two different computers. On the right is the same track extracted using dbPowerAmp R13. Top right is extracted from a Daemon virtual drive with an image from EAC mounted (looks fine, identical to EAC extracted data), and the bottom right is extracted using dbPowerAmp from the CD disk itself. Looks like 102 missing samples padded with zeros, even though EAC managed to read in to the lead out to get the actual data.

http://tenuouslink.net/blogs/gadgets/uploaded_images/dbpa_missing_samples.gif

CD ROM Technical Details:
Manufacturer: HL-DT-ST
CD Drive: DVDRRW GSA-H30L
Firmware: S856
Serial: 07/02/08
Maximum Speed: 7056 KB/sec (x40)
Current Speed: 7056 KB/sec (x40)
Spin-down After: 32 seconds
Buffer Size: 2 MB
Accurate Stream: Yes
C2 Error Pointers: No
Reads ISRC: Yes
Reads UPC: Yes

OS is Vista Ulitmate x64 (64 bit)

bhoar
08-17-2008, 05:47 PM
Is the checkbox "Read into Lead-in or Lead-out" checked for that particular drive in the dbpoweramp CD Ripper: Options dialog?

-brendan

sjmac
08-17-2008, 06:12 PM
:blush:

Actually, not!

I had looked for that kind of option, but I'd been clicking the arrow next to the options button, not the actual button, so couldn't see most of the useful options.

HOWEVER - setting it made the problem "worse" - I got even more missing samples. Then I tried changing the Communication setting, and choosing "SCSI pass through" instead of "Windows Internal" has fixed my problem (tested in R13.1 beta).

bhoar
08-17-2008, 06:29 PM
Good to hear. SCSI Pass Through allows for the largest drive capability support and should be used whenever it is avaialble.

-brendan

sjmac
08-18-2008, 02:38 PM
Noted, and thanks for your help :-)

If spoon/developers are reading, I suppose it's worth pointing out that EAC was working OK with the "Native Win32 Interface" option, which I guess is the same as dbPowerAmps "Windows Internal".

bhoar
08-18-2008, 02:41 PM
Noted, and thanks for your help :-)

If spoon/developers are reading, I suppose it's worth pointing out that EAC was working OK with the "Native Win32 Interface" option, which I guess is the same as dbPowerAmps "Windows Internal".

Actually, "Native Win32 Interface" is the same as "SCSI Pass Through", not "Windows Internal". So, you've set dbpoweramp to use the same method as EAC.

-brendan