Bit Perfect Flac Rips With Tt7

[konut 0]

I want to know if TT7 ensures bit perfect FLAC files on my harddrive the same way that Exact Audio Copy, EAC, does for XP. EAC will go back and read a section of a disc it has a problem with, ie scratch, smudge, dust, over and over again until it is confident that a bit perfect file is produced. Or, as with most OSX FLAC encoders, does it just use error correction when it encounters a problem. Also is there a provision to have a sliding scale for speed of a rip vs size of compression as EAC does for FLAC encoding..TIA

[ffooky 0]

If your drive caches audio (as the vast majority of modern drives do) then there is currently no native OS X application that can produce secure rips in the same way that EAC can. If you're lucky enough to have a drive that does not cache audio then cdparanoia, cdda2wav with lib paranoia or any of their GUI's (xACT and Max for example) can produce secure, error-corrected rips.

 

Toast's audio extraction is no better or worse than any burst ripper's but if it could be adapted to a form that could disable caching and allow for proper error correction it would be a MAJOR selling point.

 

Until that happy day, EAC under Virtual PC is the only 100% secure route.

Edited February 22, 2006 by ffooky

[konut 0]

Thanks for the bad news. I was afraid of that. You'd think that Apple of some other software outfit would have resolved this by now. Very disappointing to say the least. I hate having to even consider using an MS product but it looks like I have no other option.

[ffooky 0]

There was something, pyripper, written in Python principally for Linux by someone who frequents hydrogenaudio.org. It worked by force reading/comparing in blocks that are too large to be cached by the drive. I could never get it to run under OS X, though I believe some folks were able to. The coder has now rewritten it in ruby (rubyripper) and I think the possibility of an OS X GUI has been floated.

[konut 0]

Thanks for the heads up. As I am a casual user, when you start to talk about Linux and writing code my eyes kind of glaze over and I nod my head with out really understanding. Hopefully someone will rescue us from the sentence of an MS solution to this problem thats easy enough to use for the average/casual user.

[eytan_bernet 1]

How would you know if XAct is actually producing the error free extractions on your CD? I have used XAct and never had problems with its extraction - and it has never given me an option to find out, and the read me says it supports safe extraction...

[ffooky 0]

How would you know if XAct is actually producing the error free extractions on your CD? I have used XAct and never had problems with its extraction - and it has never given me an option to find out, and the read me says it supports safe extraction...

 

From what you say I'm presuming you've been converting straight from the CD to FLAC etc by adding the ".aiff" files on the disc to xACT's encode window. This is no better than dragging them off the disc onto your desktop in the Finder. In order to use cdda2wav w/lib paranoia you need to go to xACT's util tab and select CD extraction. Once the rip has finished, xACT will produce a (rather lengthy) log file which gives a result for each of the tracks ripped. If any of the tracks are reported as having "atom" error values then you're sunk...these are not correctable even with EAC (sync errors), but sometimes a second attempt will produce a rip free of other problems.

 

I've conducted protracted tests, ripping known damaged discs with the Finder, Toast, xACT and EAC and, in these, xACT came best of the rest on drives that cache audio. If, however, you make a number of extractions (maybe a mimimum of 3 ?) using any of the non-secure methods and obtain matching checksums for all rips on all tracks then you can be 99% certain that your rip is perfect.

 

As for drive offsets......

[eytan_bernet 1]

Well, I don't know why you are presuming that. I am using XAct to do the extraction under the CD extraction tab what I asked is how would I know that my drive is caching from looking at the results of each track? From what you just implied, it seems to produce the same results as EAC, unless you get atom errors - in which case, EAC may fail as well. Why is this not a safe reliable option? What exactly would XAct be able to tell you that would inform you that you are not producing an accurate read?

[ffooky 0]

I made that presumption because you said that you had never had the option to find out if xACT had had problems with its extraction. It always produces the log, which does precisely that, unless you by-pass cdda2wav by going straight to compressed formats.

 

As to whether your drive caches audio, this is an old database of drive features which may contain your drive, though the overwhelming majority of drives developed since this table will cache audio.

 

xACT is only able to inform you of certain error kinds (at least "atom" and "edge"...whatever on earth they actually are) but even this limited reporting is superior to none, as produced by Finder, iTunes, Toast etc.

 

I posted full results of my tests on hydrogenaudio.org and thetradersden.org but this snippet should illustrate the shortcomings of any non-cache-defeating ripper:

 

I ripped a CD with multiple tools, multiple times. One particular track stood out as illustrative:

 

Track  4
 Filename C:\Documents and Settings\Waldo Jeffers\My Documents\04 A song.wav

 Peak level 81.7 %
 Track quality 99.9 %
 Test CRC 58D43EC9
 Copy CRC 58D43EC9
 Copy OK

 

I made sure that offset correction was not applied in order to facilitate comparison with the results of other methods.

 

The same track was ripped 4 times with xACT and all 4 produced this output

recording 258.4666 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
100%  track  4 'A Song' recorded successfully

100%  0 rderr, 0 skip, 0 atom, 0 edge, 0 drop, 0 dup, 0 drift

100%  258 overlap(0.5 .. 0.5)

 

Yet these were the results when the extracted track obtained with all methods was compared

7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC3.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC4.wav
a5fdea1a598f2a68be6e55585107ebf2  [shntool]  LO_Finder1.aiff
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Finder2.aiff
7b826dea52078c8cea25847fd361c985  [shntool]  LO_iTunes1.wav
4876a55f547c70f000ee8ace94ef2a27  [shntool]  LO_iTunes2.wav
f6a027fea6664bfec81e39deb61ea2b1  [shntool]  LO_iTunes3.wav
b9610ce44fadcc4da5bfef3271ce7d41  [shntool]  LO_Toast1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Toast2.wav
92136c8a759964fe0b359f5607b8c717  [shntool]  LO_xACT1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_xACT2.wav
243eb0cae251aa05d00531e063fae24d  [shntool]  LO_xACT3.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_xACT4.wav

This clearly shows that a error-free log from xACT is not a guarantee of a 100% secure rip.

[konut 0]

This is exactly the type of discussion that I'd hope would occur. Let me see if I've got this straight with a hypothetical example. Say that I use a MacMini with xACT set the way you have outlined, util tab with extraction, will I then get rips that are bit perfect? Or close to bit perfect? Will MAX do this? (I've heard MAX is easier to use) If not bit perfect, would it be anything to worry about as long as atom and edge are ok?

Edited February 26, 2006 by konut

[ffooky 0]

If your disc is undamaged then either xACT or Max are extremely likely to give you bit perfect (though not offset-corrected) rips. It's also highly likely that Toast and iTunes would produce similar results, though there do seem to be instances where a tiny, almost certainly inaudible discrepancy can occur and the *nix based tools are "safer". I personally prefer xACT as I find its GUI less confusing and its log far easier to read. As to which is more accurate, I think the answer is neither.

 

Whatever number of 100% identical rips you consider sufficient is the very best way to achieve a degree of accuracy you can be confident with. You can safely bet that any errors that go unreported, such as those in my example above, are going to be 100% inaudible...the great thing about rippers that do produce a log is that you have a chance to listen and decide for yourself whether the knowledge that something is not absolutely accurate is outweighed by the fact that you simply cannot hear it

[konut 0]

Thanks for setting my mind at ease about getting good rips. Now you've given me something else to obsess about, offset correction. In my previous example, if I'm using a MacMini with a built in drive do I have to be concerned about offset correction? It it already taken into account? Is offset correction only a factor when using external optical drives?

[ffooky 0]

All drives require some degree of offset correction. I'm not sure which drive your Mini is equipped with but I know the Pioneer DVR-K04L is compatible. Looking that drive up in this database you can see that it requires a read offset correction value of +48. This means that in an uncorrected rip, all the tracks will be positioned wrongly by 48 samples; in terms of time that's 48 divided by 44100 = 0.0010884 of a second.

 

The day I'm bothered about the relative postioning of 0.0010884 of a second, which will of course be silence with studio recordings, is the day they can take me outside and shoot me. The argument in favour of fastidious correction of offsets is that for unofficial recordings, live tapes etc, after x amount of extractions some amount of actual audio data may be lost. The fact that this audio data will 99.9% certainly be the murmur of the crowd is irrelevant, I think the desire for EXACT equivalence is so that checksums will never vary between copies allowing for people to check that they have exactly the same generation of a show.

 

The issue with offsets and, to some degree, error correction is pretty much psychological. It would undoubtedly be nicer to have exact equivalence but we're never realistically going to notice if we don't.

 

That said, please Roxio, give us a secure ripper...even nice people damage their discs....

Edited February 26, 2006 by ffooky

[eytan_bernet 1]

Thanks so much for the info. Now I get it much more. Since I rarely do EAC since I tape and burn from raw files, this is not much of a concern for me - but I now understand the issue.

Thank you for all your knowledge - now if we could only talk Roxio into allowing us to produce music DVDs without gaps...

[hermie54 6]

I just read on the Max forum that the developer is looking into making an EAC equivalent for Mac. Lotsa problems though.

[konut 0]

I just read this statement on another forum.

 

" It appears that iTunes IS bit perfect if you disable a few of their presets and rip WAV or AIFF."

 

If this is true, would it be possible to take the resulting file and transcode it to FLAC using TT7 or any other (read free) transcoding app? Thanks for humoring my obsessive/compulsive tendencies regarding this.

[ffooky 0]

If this is true

 

It ain't.

 

No one on any public forum I'm aware of has any knowledge of what precisely iTunes's error correction consists of but whatever it is, it is not secure. Look at the results of the rip with iTunes I posted above...3 rips, 3 differing checksums. Case dismissed I'm afraid.

I imagine that some amount of rereading takes place but that the cache is not flushed between reads.

 

Defeating audio caching is the key to security; it would seem to me that Apple, with their software/hardware integration would be in a great position to accomplish this and the fact that they introduced error correction at all shows they have some interest but sadly I think it's as far as they'll go.

Edited February 28, 2006 by ffooky

[konut 0]

This is the link to the forum where the claim about bit perfect rips in iTunes is made.

 

http://www6.head-fi.org/forums/showthread....nes+bit+perfect

 

From the level of discussion I suspect that they are wrong and you are right ffooky. Oh well, ignorance is bliss. My reluctance to join yet another audio forum will insure their bliss, unless you decide to burst their bubble and set them straight.

[ffooky 0]

As it 'appens I'm already registered over there but I don't have the energy at the moment to encounter people who may not want to accept incontrovertible evidence.

 

I'm going to guess you're registered at hydrogenaudio so you may well have met the "FLAC/ALAC/APE doesn't sound as good as WAV" brigade.

[konut 0]

LOL, no, I seldom go to Hydrogen much less registered there. I'm more from the old school audiophile side of things. For me the minimum quality for audio is 16/44.1 weather wav, flac, ape, or aiff. The reason I'm interested in flac is that its the native, and most efficient format for the Slim Devices SqueezeBox.

[igroucho 0]

So where do we stand now 9 months later (a digital eternity) on this subject? I want to transfer my cd-collection (or as much as I can endure) to bit perfect copies for playback from an ethernet drive thru Slimdevices devices, either Transporter or Squeezebox, with immidiate access to data such as title/trax etc. My Windoze audio-friend does this with EAC. Can I achieve the same perfection thru Mac or do I have to resort to pc?

As user-friendly as possible since I'm as lazy person as the next guy.

[ffooky 0]

There have been some advances, including a near-as-dammit secure ripper for linux (RubyRipper) but that is not yet ported to/compilable under OS X and an attempt at a comparison ripper as part of Max but for the most secure DAE currently available, to the Dark Side must you go.

[eytan_bernet 1]

We should really do a test of ripping to AIFF using iTunes with error correction turned on, Toast, and a PC using EAC and do a compare. Has anyone done that?

[ffooky 0]

We should really do a test of ripping to AIFF using iTunes with error correction turned on, Toast, and a PC using EAC and do a compare. Has anyone done that?

I'm not sure if you can read the forum without being registered but I did a very lengthy series of tests using xACT, Toast 7.0.1 and EAC running under Virtual PC in this thread.

 

I ripped a track that produced problems in a first set of tests, multiple times with EAC, xACT, Toast 7.0.1 and by dragging to the Finder (OS X 10.3.9). Unfortunately I was unable to include cdparanoia as I could not get it to recognise my external drive.

 

With the EAC rips I shut down the virtual machine, closed Virtual PC and then deleted the Undo Drive file between rips as well as turning the CD drive (external (Firewire) 'LITE-ON ' Model 'LTR-24102B ' Revision '5S57') on and off so there was absolutely no chance of anything being cached. Error correction lights were lit (one row) at varying points of all test and copy routines.

7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC3.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_EAC4.wav
a5fdea1a598f2a68be6e55585107ebf2  [shntool]  LO_Finder1.aiff
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Finder2.aiff
7b826dea52078c8cea25847fd361c985  [shntool]  LO_iTunes1.wav
4876a55f547c70f000ee8ace94ef2a27  [shntool]  LO_iTunes2.wav
f6a027fea6664bfec81e39deb61ea2b1  [shntool]  LO_iTunes3.wav
b9610ce44fadcc4da5bfef3271ce7d41  [shntool]  LO_Toast1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_Toast2.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_UNQUIT_Finder.aiff
4fe6f039c146db5489b7ce10acfac10a  [shntool]  LO_UNQUIT_Toast.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_UNQUIT_xACT.wav
92136c8a759964fe0b359f5607b8c717  [shntool]  LO_xACT1.wav
7931b23da6c5b8bf4ce71bee1448c327  [shntool]  LO_xACT2.wav
243eb0cae251aa05d00531e063fae24d  [shntool]  LO_xACT3.wav
bb580449b92e51764678c1d41f4f7df8  [shntool]  LO_xACT4.wav

As you can see, EAC was the only ripper that managed to produce identical results with multiple rips.