Rip guide for perfectionists Options

[RamonSalazar]

Hi all!

Ive read topics about EAC's offset is 30 samples away from the absoulute zero point. Some ppl think that ripping without overread will result less perfect rips.

I say the chances are enormous that read offset correction or overreading is only makes sense to match your rip with te accuraterip database.

Why i say that? Because the 99% of the Audio CDs contains enough null samples at it's beginning and at it's end to make this noise useless. Especially, since you can not make sure you've digitalized the whole disc without this check. Let me show this to you:

1. How to check the amount of null samples at the beginning or at the end of an album?
You will need to have SHNTOOL.EXE copied into your path (For example C:\Windows). Let's suppose the rip's folder look like this:

Open command prompt (start->access->), and go to the rip's folder. In this case you need to convert the .flac files to .wav-s first, but if you've unchecked the deleting of wave files in EAC's compression options you might have the .wav-s already. Ok, first you have to convert the first and the last tracks into .wav format:

CODE

shntool conv -o wav 01_Castellorizon.wav "10_Where We Start.wav"

You can use the TAB key to rotate between the possible file names after you've typed 'shntool cnv -o wav '. Ok, next you need to do to trim the silence (null samples) from the beginning of the first file and from the end of the last file:

CODE

shntool trim -b 01_Castellorizon.wav
shntool trim -e "10_Where We Start.wav"

Screenshot:

Your folder should look like this:

Now you only have to do to calculate the amount of null samples. To determine the amount of null samples, divide the difference of the two file sizes by 4:
Beginning: 45027 = (41324684-41144576) / 4 = 180108 / 4
End: 90539 = (71618444-71256288) /4 = 362156 / 4
If both values are significantly higher than the read offset, then you can delete the .wav files and consider your rip to be really exact. If you dont want to make complicate calculations, you can check it fast if the original wav file is more than 10000 bytes (2500 samples) greater. That should be enough (since the highest known read offset offset is +1776).

Why is this check important? Let me show you what to do if shntool reports that no silence (or less or equal than the drive's read offset value) exists at the beginning or at the end of a rip.

2. What can cause if there are not enough null samples?
Let me show you an example: This is Robert Plant's Dreamland album:

And the folder:

You can notice that no '01 - ... -trimmed.wav' was created and the difference is 120bytes (30 samples) between the two files of last track. The rip was made with a PX-W5224A which has +30 read offset and athe Overread checkbox was unchecked. EAC simply filled the last 30 samples with nulls: That is the reason for the 120 bytes difference. The beginning of the first track:

You can see the silence got a small DC offset which caused it not to bacame 'proper' silence. Same with the end of the album.

3. What to do?
If you are a perfectionist, you have to re-rip the first and the last track. You must have an overread compatible drive. If you don't have one, be satisfied with your very-exact (not very-very ) rip.

You will need to rip the not well positioned album. To do this you have to align your drive onto the albums range. EAC with default offset correction will try to rip the grey area (30 -- E+30), however the last 30 samples of this area is unnecessary, and it makes the first 30 samples lost. To make this EAC changes the drive's read laser's position to the EAC's zero position. However the black stipes on the bottom of the drive's rectangles represents the area the drive can normally read. If you want to read outside this area, the drive have to read into the lead in/out.

The null sample value test is necessary to make sure that

1. there are null samples after the lost area (thus the lost area have to consist of nulls)
2. for drives with negative offset correction: there are null samples after the overread (into lead-in) area
3. for drives with >30 offset correction: there are null samples before the overread (into lead-out) area
4. there are no data loss due to bad positioned album

High percentage of the albums are positioned not to the absolute or EAC's zero point. Fortunately high percentage of albums contains enough null-samples at theirs beginning and at theirs end to make theirs zero position irrelevant. If you rip to the outer area you will get also null samples, thus if the album contains nulls at it's beginning and at it's end, you will not be able nor necessary to detect it's theoretical starting position.

Unfortunately Robert Plant - Dreamland is not an ideal album. With PX-W5224A (+30 read offset correction) I had to make this:

1. Re-rip the last track with offset correction and overread enabled (the drive have to be able to overread into lead-out)
2. Re-rip the first track with smaller (usually normal offset-30) offset correction (for PX-W5224A: 0!)

Note: Of course if i had ripped the album originally with overread enabled i would not have to re-rip the last track again.

You have to check the figure to figure out what to do with your drive. Keep in mind that normally your drive can read the black striped area. It have to be able to overread into one or both direction to make the readable area aligned to the album's area.

After i've repeated the trims to the new files i got the following results:
First track (ripped from the absolute zero) contains 18 null samples at it's beginning.
Last track (ripped with +30 read offset correction and overread) contains 12 null samples at it's end.

Conclusion:
The whole area of the album consists non-null samples, and it is positioned to +18 samples from the absoulte zero and -12 from EAC's zero.

4. Keep the data
Because of the accuraterip matches it is not a good idea to rerip the whole album with read offset corection aligned to the album's starting position. That method would result no accuraterip checking.

In this particular case it is easyer with the last track: However the overread enabled and the originally ripped last track have different EAC crc-s, the Accuraterip CRC-s are the same -- both matches to the database (because AR doesnt make checksum to the whole area). I've simply kept the overread enabled last track.

From the newly ripped first track i only need the first 30 samples. SHNTOOL can split wav datas, but it needs the split points by bytes (1 sample = 4 bytes):

CODE

shntool split <RERIPPEDFIRSTTRACKWAVE>
120

After typing the spilt point (in this case:120) hit F6+Enter. Shntool will split the wave and will produce a 'split-track01.wav' and a 'split-track02.wav'. I could freely delete the 'split-track02.wav' and the re-ripped first track wav. I only needed 'split-track01.wav' which is 30 samples long but its file size is 164 bytes. This is because all wave files contains a 44 bytes long header. I had to get rid of the first 18 null samples. To do this i've used shntool's trim command again. Finally i've got a 92 bytes size .wav containing 12 non-null samples: from between the albums start point and EAC's zero point. Rename it to 00.wav and copy it to a Misc folder. THAT IS A PERFECT RIP!

5. How to burn it exactly back?
It is recommended to keep the original tracks ripped form EAC's zero point due to the compatibility. However if you want to burn a very-very-very exact copy of such a non-well masterized and positioned album, you will have to use the small file created in the previous point. You must have a single image CUE sheet. If you dont have one, create it with CUE Tools.

Do the following:

1. Trim the null samples from the last track's end with shntools
2. Copy 00.wav next to the album tracks' files.
3. Join them together:
   CODE
   shntool join -n 00.wav <TRACK1FLACORWAV> <TRACK2FLACORWAV> ... <TRACKN-1FLACORWAV> <LASTTRACK-trimmed.wav>
4. Set the drive's write offset to its normal write offset adjusted with the difference between EAC's zero and the albums zero. In this case NewWriteOffset=DefaultWriteOffset+12=-30+12=-18!!! Remember the difference between offset and offset correction! EAC asks for 'read offset correction' but 'write offset'!. Use this write offset setting to this album only!
5. Burn the produced joined.wav to CD-R using the single image CUE sheet (probably you will have to edit the file name manually inside the CUE sheet...

Conclusion
I would like to see if ripping software would automatically report in the log file the amount of null-samples at the beginning and at the end of the ripped material. That would save time.

Thats all, hope you enjoyed it... Hehehe.

Cheers,
RS

This post has been edited by RamonSalazar: Apr 30 2008, 09:00

[valnar]

Or you can just rip with a Plextor PX-760A and burn with an LG GSA-H10A.

[greynol]

I say the chances are enormous that read offset correction or overreading is only makes sense to match your rip with te accuraterip database.

I'm not sure what you're getting at exactly (this sentence doesn't make sense), but AccurateRip ignores the first 2940 samples of the first track and the last 2940 samples of the last track in order to compensate for drives that can't overread. IOW, unless your offset is greater than 2940 or less than -2940, overreading has absolutely no bearing on the ability to match your rip with AccurateRip.

5. How to burn it exactly back?
It is recommended to keep the original tracks ripped form EAC's zero point due to the compatibility. However if you want to burn a very-very-very exact copy of such a non-well masterized and positioned album, you will have to use the small file created in the previous point.

You've completely overlooked the fact that very few drives can actually overwrite into the lead-in/-out.

Or you can just rip with a Plextor PX-760A and burn with an LG GSA-H10A.

If you are really keen on this business with a shift in reference by -30 being the true one (), you rip with a Plextor PX-7XX or Premium with 0 entered for the read samples offset correction and burn with any (true) Plextor with 0 entered for the write samples offset. This way all the samples based on the supposed true offset can be read as well as burned. If you go with the Andre's reference (the standard!) then what you said is absolutely correct.

In order to preserve these "critical" () non-null edge samples you need to burn with a drive that either has no write samples offset, can overwrite into the lead-out if the write samples offset is negative (only a couple of obsolete Teac drives can do this), or can overwrite into the lead-in if the write samples offset is positive (this is a more generic case, but still there are few reports of drives being able to do this either).

[bhoar]

In order to preserve these "critical" () non-null edge samples you need to burn with a drive that either has no write samples offset, can overwrite into the lead-out if the write samples offset is negative (only a couple of obsolete Teac drives can do this), or can overwrite into the lead-in if the write samples offset is positive (this is a more generic case, but still there are few reports of drives being able to do this either).

I know curiosity killed the cat, but which obsolete Teac drives? Since I have a handful of old Teac drives here in my collection.

-brendan

[greynol]

http://www.digital-inn.de/23683-post3.html
http://www.digital-inn.de/129392-post15.html

[RamonSalazar]

I'm not sure what you're getting at exactly (this sentence doesn't make sense), but AccurateRip ignores the first 2940 samples of the first track and the last 2940 samples of the last track in order to compensate for drives that can't overread. IOW, unless your offset is greater than 2940 or less than -2940, overreading has absolutely no bearing on the ability to match your rip with AccurateRip.

Ok you have rigth with overread but if you don't set the necessary read offset correction, EAC will not check for AR matches. Sorry for my bad english, it is not my main language.

You've completely overlooked the fact that very few drives can actually overwrite into the lead-in/-out.

Yes but ripping the whole content is possible with a lot of drives (pl,pion,yama...) I also said that not a big deal if the drive is not capable to do this 'only for perfectionists' method. Some samples lost is not to worry about. But IF you at least can read it why dont do it? IF you can burn it exactly back too, that is a bonus. I've also said that this magic trick would only make sense for a very few disk. Of course nobody can actually hear the difference between a null and a +1/-1 sample.

Cheers,
RS

This post has been edited by RamonSalazar: Apr 29 2008, 20:50

[Aramys]

Hi,

About this so-called absolute zero reference offset, there is something I don't really understand now when I compare offset values of Plextools Pro XL and EAC. I read somewhere that both Plextools and EAC were using the same "30 samples off" read offset value originally calculated by Andre but that's not what I see. I have a Plextor PX-130A DVD-ROM and the read offset values are the following (given by the softwares) :

- Plextools Pro XL : -2832 bytes = -708 samples (read offset)
- EAC (AccurateRip) : +738 samples (offset correction corresponding to a -738 samples read offset). This value should be decreased by 30 samples to be at the "abolute zero" value ie 708.

So... if I understand correctly, Plextools Pro XL really uses the absolute zero reference offset value which is different from the EAC (AccurateRip) value.

Did I miss something ?

Aramys

This post has been edited by Aramys: May 10 2008, 19:50

[RamonSalazar]

Although I don't know Plextools much, your conclusion seems correct to me. I must aware that these hyphotetic zero points do not apply to the real discs: They have various zero points.

1. Unfortunately if your drive don't rip from the album's reference point by default, it have to be able to overread to rip the entire disc.
2. Fortunately there is a high probability that the missing parts contains only null samples,
3. Which causes that the own zero point of the disc irrelevant and undetectable.
4. More important criteria against the software's reference point to be single and close to the expected value of the disc's zero point.
5. EAC's (and AR's) ref point meet these conditions.
6. However there could be some audio CD-s which have audio data out of the default EAC range (For example the one I've presented, or some old AAD discs).
7. That's why I use silence checkout for the first and the last track, and if it's necessary I rerip the first and/or last track with another read offset correction. I personally save the difference into small .wav files, and I make a batch file which produce the image.wav from the album's zero point. How? It join the small file to the beginning of the first track and cut the same length from the end of the last track, or opposite.
8. Why?

   You've completely overlooked the fact that very few drives can actually overwrite into the lead-in/-out.

   To give another answer: My method overcome (or at least equal good than) the standard, even if writer is not able to overwrite.
   
   
9. I highly advice to rip from EAC's zero; use the standard method. Only when silence checkout fails there are more things to do. Therefore if Plextools adjust your read head to the absolute zero, i won't use it. A >=4 AR confidence is better guarantee than T&C CRC match or anything else.

I've posted to EAC forum the request that EAC should report (LOG) the length of silence at the beginning and at the end of the album.

This post has been edited by RamonSalazar: May 14 2008, 12:53