Consistent rips

[dragonne]

I am continuing my evaluation (at this point I expect to get the family professional pack, it is looking good).

I have gotten binary comparable outputs by running

metaflac --export-tags-to=- %1.flac | sort > %1.tag
metaflac --preserve-modtime --dont-use-padding --remove-all %1.flac
metaflac --preserve-modtime --dont-use-padding --import-tags-from=%1.tag %1.flac

for all generated .flac files. I have ripped a number of test cds. One of which is unrecoverably bad, one which has a mix of "Secure" tracks and "Accurip" tracks, some that are all "Secure" tracks and some that are all "Accurip" tracks. I have ripped all of these on two different machines. For one machine I got an extra CD drive which turned out to be by the same manufacturer and had the same offset (it was pot luck, oh well). Only about 30% of my initial test sample happens to be in the Accurip database.

The bad CD is consistent across systems. Some drives will rip one of the tracks sometimes and others won't. Cleaning and repairing the CD makes no difference. There is no apparent damage to the CD. Probably a bad pressing. I don't consider this CD to be an issue. Some CDs are just bad.

Of the good CDs, all but two are completely identical when ripped on different machines. The remaining two are identical for all tracks except for the final track. The final track on one machine has 148 binary zeros in the .wav file at the end where the other .wav file has data. The machine with binary zeros has an offset of 102 and the machine with the data has an offest of 30. This exactly explains the size of the difference (102 - 30) * 4 = 148.

However, neither of these CDs have 80 minutes of playing time. One has 69:00 and one has 58:40. Further, the new CD drive can supposedly read past the end (according to EAC). So, in theory, the read offset should not be causing a problem. But, clearly it is.

So, why should this difference happen? It is repeatable with both dbPowerAmp and EAC, so I don't think either program is likely in error. This must be a physical limitation of the drives.

It appears to me that I can only assume a "perfect" rip is even possible when the drive has an offset of 0 -- or certainly as small as possible (perhaps 6 would be ok).

If that is the case, I need to buy a new drive for ripping. What would be the best zero offset drive (IDE interface for an internal drive or SATA in an external enclosure) to get for ripping? Preferrably, internal, I would probably put one on each system.

I looked at the drive accuracy list, but I suspect that it has less to do with the drives than the random mix of good / bad CDs that the drives were used on.

Otherwise, I still don't have a complete solution for controlling .flac ==> .mp3 conversion with control over the tags and encoding options. I have not (yet) looked at the CLI as you suggested. I have not been able to find a .mp3 command line tag editor than can read metaflac tag files and write to a .mp3 file. That would be very nice and ideal because everything could be done in batch files after the initial rip and verification. I have seen some linux / unix shell scripts to convert .flac to .mp3, but those are useless for Window.

It would also be VERY nice if dbPowerAmp ran on Windows 2000. I have older machines still using W2K (and always will, they can't handle newer OSes). Those have some nice (but older) CD / DVD drives that I could use for ripping. I paid big bucks for CD / DVD drives back then. Likewise, my XP machines will never run never OSes for the same reason.

Thanks.


Michael Lee Finney

[Spoon]

Re: Consistent rips

Zero offset drives do not exist, 6 is as close you will get. Your drive has to be able to overread to read those samples which would normally be lost, for most people (including my self) missing 6 samples is not going to cause any issues.

[dragonne]

Re: Consistent rips

Your list of drive offsets shows 15 drives with 0 offset and 997 with an offset of +6. However, it does NOT list which drives can overread. I could randomly order drives for months before finding one that works right. I was hoping for a more specific recommended list of drives.

For example the PLEXTOR - DVDR PX-820SA is listed with an offset of 0 / 2 and the PLEXTOR - PX-716A is listed with an offset of +6 / 1. However, probably most of those drives listed are not available, they may be very old and they may or may not support overread, C2 and other features.

So can you provide more information? Or at least add more information to the drive list to include supported features to narrow a search?

Thanks.

[biggles]

(102-30) * 4 does not equal 148.

I am not aware of any conversion software that provides more control over tagging from FLAC to mp3 than dBpoweramp, and I've looked extensively. Other applications provide similar capability that is more difficult to use (foobar, EAC), some provide similar tagging flexibiltiy but more suspect conversion ability (many others).

Put another way, no ripping or converting software allows direct access to mp3 frame assignments and formatting, so some post-processing is likely. You should feel very, very comfortable using dBpoweramp for everything other than Replaygain tag creation.

FWIW, I use Foobar for Replaygain tag creation and Mp3tag to perform all tag processing after ripping or transcoding.

If you are a very picky person on this stuff (I think I am as well), then the decisions you make regarding if and how to deal with HDCD discs, Replaygain tags, any pre-emphasized discs will have a far greater effect on your satisfaction of your rip results and time efficiency than the theoretical limits of dBpoweramp or EAC.

[dragonne]

Re: Consistent rips

I am very picky. But, I compartmentalize different aspects of the problem. The first problem is just to get consistent binary .wav files from the CDs. The second problem is to get tags. dBpoweramp does both of those quite nicely. I have now registered for the professional family pack and installed the registered version. So...

1. Step 1. Rip securely using dBpoweramp into .flac format keeping all possible tags. Once a disk is ripped, do a normalization batch step for the tags. Do any special editing, if needed, on the tags and reapply the tags (only needed for the ocassional CD).

That is all working and gives me binary consistent results for the same CD across different machines and different CD drives with the exception of the two CDs previously mentioned. I still need a better CD drive to do the ripping. This step is the most important because it gives me the base audio library and will not need to be repeated. Everything after this step is post processing of one form or another.

2. Step 2. Convert to .mp3 and other formats as needed. As the encoders improve, or I need different formats this step can be done repeatedly. I prefer to do this step as a batch file, but using a GUI that can work recursively is ok also. For .mp3 it is clear that LAME is probably the best encoder currently available. However, I have discovered a bug in LAME when it uses assembly language. Enconding the same .wav file on different machines using default options gives different .mp3 files. That should never happen. I have reported that bug, and hopefully it will be eventually fixed. In the meantime, I need to use specific LAME flags during encoding. There is also the issue of inserting the .mp3 tags that I want automatically. There are bash/sh scripts to do the deed, but not for Windows. I haven't found anything yet, so I may need to create a program to fire off the various command lines. However, possibly dBpoweramp can be used for this as well. There is a CLI feature that I have not yet had time to investigate.

I consider the issues with (2) to be resolvable, one way or another. They are also not critical to reripping 1,000+ CDs. However, (1) is critical. Everything is now solid except for the CD drive used for ripping. I can't order hundreds of CD drives to find one that works just right, so I am looking for recommendations. Clearly, it should have the smallest possible offset (0 or +6), it should support C2 and it should support overreading. This is why I need a drive recommendation. There are too many to choose from and no way to know which features the drive supports before installing and configuring it. The drive offset list is a good start but it doesn't include C2 support or overreading.


Michael Lee Finney

[dragonne]

Re: Consistent rips

I have found that the Plextor PX-716A with firmware revision 1.11 (but NOT 1.08) supports overreading. Once I discovered that, and upgraded the firmware for the 716a that I already have, it was able to prefectly rip my three test cds that write all the way to the end. That was not the case with the 1.08 firmware.

This drive is still available as a refurbished drive, so I have ordered a second drive for my CD ripping system.

According to www.daefeatures.co.uk it also supports HTOA and its offset is only +30, so that makes it essentially perfect for ripping.

I also have a iHAP422-98 on the way which possibly, with the right firmware, will do the same with an offset of +6. If I can get that one to work as well, I will post another reply to this thread.

[Johnny Moondog]

Re: Consistent rips

Can you tell me the source you found for the refurbished Plextor PX-716A ?

[dragonne]

Re: Consistent rips

Sorry I didn't see your question sooner.

I got mine from eBay. I don't see anything there from that specific vendor at this time. However, a quick eBay search returned about a half-dozen hits for used units. A quick google search returned at least a half-dozen hits for refurbished units. I searched for px-716a with refurbished a required keyword using advanced search and then hunted through the results. Searching for refurbished cd drive on PriceWatch turned up quite a few. One for the 716a and some for a number of the desirable Plextor drives -- although the prices for some of those are in excess of $500. From what I see the px-716a and iHAP422-98 are the most current drives that support HTOA and overreading.

Note that the PX-716a that I got had an apparently REALLY old firmware version (prior to 1.00!). However, I flashed it with 1.11 and it was able to read by test CDs. Currently 6 out of 33 test CDs require overreading to get a perfect rip.

I got the iHAP422-98, but it turned out to not support overreading. Apparently the hardware version is now "W" and "9" is needed to flash the WL1F firmware. I am currently looking for an iHAP422-98 9. Most places don't specify the hardware version, but I think I will be able to find one with a bit of looking. I didn't know about the hardware version when I ordered the one that I already got.

[Pandor]

Re: Consistent rips

...
I got the iHAP422-98, but it turned out to not support overreading. Apparently the hardware version is now "W" and "9" is needed to flash the WL1F firmware. I am currently looking for an iHAP422-98 9. Most places don't specify the hardware version, but I think I will be able to find one with a bit of looking. I didn't know about the hardware version when I ordered the one that I already got.

Don't bother. I bought a Lite-on "IHAP422-98 9" and it doesn't overread. Tried WL1k and WL1N firmware.
daefeatures.co.uk's db is incorrect.

[dragonne]

Re: Consistent rips

Don't bother. I bought a Lite-on "IHAP422-98 9" and it doesn't overread. Tried WL1k and WL1N firmware.
daefeatures.co.uk's db is incorrect.

I have ripped a couple of hundred CDs at this point. I mostly use the PX-716a (the first one turned out to be defective and I got another and a replacement so I now have three -- one of which works, but does not appear to be quite as reliable as the others for certain disks). However, on some CDs where I have had problems, I have found that apparently the IHAP422-98 W DOES read into the gap EXCEPT for the last track! I am not 100% sure of this, but I have had tracks that I ripped using it where the data in the .wav file (using a binary editor to look at it) went all the way to the end. There should have been 24 bytes of zeros if it was unable to read into the gap. It could be the iHAP422-98 9 (which I was never able to find, I have an extra W because of that) is the same way.