Page 1 of 2

Is MAX the Mac Equivalent to EAC? Also Lame 3.96

Posted: Wed Jul 19, 2006 4:30 am
by mieler217
Hi all,

I just got my new MacBook a week ago (I love it) and am trying to find a Mac program that is similar to Exact Audio Copy. After reading the description of the program and trying it out, I think MAX may be what I'm looking for. Any one else have any opinions? Has anyone run EAC thru Parallels?

Also, is there a way to get lame 3.96 into the latest version of MAX?


Thanks a lot,
Mike

Posted: Wed Jul 19, 2006 6:25 am
by krmathis
It might not be on par with EAC when it comes to secure ripping, yet.
But it is better than cdparanoia and iTunes, which pretty much are the only alternatives on Mac OS X.

Regarding LAME 3.96. You would need to build Mac from source. But first you have to build LAME 3.96 as a framework.
I don't see why you want this though? Cause 3.97b2 is the recommended version, which produce better sounding files than all previous version.

Posted: Wed Jul 19, 2006 2:17 pm
by Fuga
krmathis is correct re: comparison to EAC. Max isn't there yet but is close and the developer is working as hard as he can.

As for LAME, Max does it differently than most are used to. It's not that I don't trust it yet, I just haven't bothered to figure the tweaking of settings to be what I am used to in more "standard" LAME use. For example, there is no way to enter your own switches.

If you are comfortable at the command line you can do that. There are several GUI wrappers for it as well. Last I checked the most used is iTunes-LAME (see versiontracker.com). I am not sure which LAME it now comes with but you can substitute your own.

Having said all this, as desired as EAC parity is, for *personal* use many who use EAC for sharing are content with MAX for ripping. Plus, even when I do use EAC I do so only for the rip itself. Everything else lossless I use Max and it's brother, Tag.

As for EAC/Paralllels, it's not there yet either. There have been few reports on actual use. In one Parallels forums thread, a response seeming to come from someone "official" IIRC, they are aware of whatever issues there are and think they can address them. If you know of Paralles you must know of BootCamp. You may also know that what BC creates it can make go away. My plan is to grab me a copy of Windows, do the BC thing, cope with having to reboot, wait for when Parallels is right, then switch, and deal with the hassle of re-setting up Windows.

Posted: Thu Jul 20, 2006 3:38 am
by kstlfido
Hi- Just started using max. I am curious- why is it not as good as EAC for ripping? Seems if you set high rip and paranoia settings, shouldn't that do just as good?? Bit of a newbie here!

Posted: Thu Jul 20, 2006 7:53 am
by sbooth
kstlfido wrote:Hi- Just started using max. I am curious- why is it not as good as EAC for ripping? Seems if you set high rip and paranoia settings, shouldn't that do just as good?? Bit of a newbie here!
Since I'm a bit biased, I will leave the opinions to everyone else :)

One tidbit of information that is important to understand is that almost all drives cache audio data, so cdparanoia may or may not produce good results on these drives with all discs. It depends on several factors such as the physical condition of the disc, the drive, etc.

I will say that I think the svn version of Max's comparison ripper (with C2 error detection) is comparable to EAC in test + copy mode. The obvious exception would be support for drive offsets. EAC's secure mode is probably a different story, and until I can figure out how to disable drive caching (I currently don't think there is much to figure out; I'm not sure I can accomplish what I need) it unfortunately seems it might stay that way.

Posted: Thu Jul 20, 2006 7:48 pm
by habesct
sbooth wrote:EAC's secure mode is probably a different story, and until I can figure out how to disable drive caching (I currently don't think there is much to figure out; I'm not sure I can accomplish what I need) it unfortunately seems it might stay that way.
I just found this app and cannot wait to use it. I was over at hydrogenaudio and someone said the following in this discussion:

http://www.hydrogenaudio.org/forums/ind ... 6891&st=25
FWIW, there is no software that can "turn off" drive cache unless it alters the drive's firmware.

EAC, for example does not "turn off" drive cache. It asks a drive to read more data than what the cache can hold so that the portion of the data that it is interested in comparing at any given moment must be physically read from the disc a second time. This process is called flushing.

The end result may be as if cache is turned off or overridden, but these terms can often be misleading since they obscure the process.

Edit: Now there is a force unit access command that is supposed to bypass a drive's cache if the drive supports it and I've also seen it suggested that some drives may no longer cache audio data when instructed to extract at low speeds. In these cases cache may be bypassed and perhaps one can make the argument that it is being overridden, but it is still not being "turned off".
Hope that helps some.

Posted: Thu Jul 20, 2006 7:51 pm
by NoName
The solution for me was to thoroughly evaluate all the optical drives I have at my disposal. Fortunately, I had a few to work with. I ended up taking the NEC ND-3500AG out of my PC and installing it in my PowerMac G4. The drive does NOT cache audio data, has a read offset of only +48 samples, has accurate stream, and detects (accurately) C2 errors.

Using Max, rips with this drive match those on my PC (using a Plextor PX-230A and PlexTools Professional as well as EAC), except for the matter of the trivial 48 samples.

I would strongly recommend the NEC ND-3500AG to anyone using Max. For the price and the features, you probably can't do better on a Mac. Period.

Posted: Thu Jul 20, 2006 10:55 pm
by Fuga
habesct wrote:
sbooth wrote:EAC's secure mode is probably a different story, and until I can figure out how to disable drive caching (I currently don't think there is much to figure out; I'm not sure I can accomplish what I need) it unfortunately seems it might stay that way.
I just found this app and cannot wait to use it. I was over at hydrogenaudio and someone said the following in this discussion:

http://www.hydrogenaudio.org/forums/ind ... 6891&st=25
FWIW, there is no software that can "turn off" drive cache unless it alters the drive's firmware.

EAC, for example does not "turn off" drive cache. It asks a drive to read more data than what the cache can hold so that the portion of the data that it is interested in comparing at any given moment must be physically read from the disc a second time. This process is called flushing.

The end result may be as if cache is turned off or overridden, but these terms can often be misleading since they obscure the process.

Edit: Now there is a force unit access command that is supposed to bypass a drive's cache if the drive supports it and I've also seen it suggested that some drives may no longer cache audio data when instructed to extract at low speeds. In these cases cache may be bypassed and perhaps one can make the argument that it is being overridden, but it is still not being "turned off".
Hope that helps some.
Stephen, has this post, especially the portion pertaining to EAC and fooling caching, gotten you to wondering about cache again? It made me go back and read the whole 5 pages of the Secure Ripping thread. In particular I keep coming back to the following. (I apologize for still not figuring out how to hyperlink in forums.)
So, the problem is, ripping would be unbearably slow if in between each sector read (a sector is only 2352 bytes of audio) you had to read 2MB+ of data you don't care about just to fill the cache with "junk", before re-reading the single sector. If each sector was retried 20 times, that would be 40 MB+ of extraneous reads just for cache clearing.
Has any one ever done the math? Has any one actually thrown together the necessary code and given it a whirl to see how long it took?

Posted: Fri Jul 21, 2006 12:12 am
by sbooth
Fuga wrote:Stephen, has this post, especially the portion pertaining to EAC and fooling caching, gotten you to wondering about cache again? It made me go back and read the whole 5 pages of the Secure Ripping thread. In particular I keep coming back to the following. (I apologize for still not figuring out how to hyperlink in forums.)
So, the problem is, ripping would be unbearably slow if in between each sector read (a sector is only 2352 bytes of audio) you had to read 2MB+ of data you don't care about just to fill the cache with "junk", before re-reading the single sector. If each sector was retried 20 times, that would be 40 MB+ of extraneous reads just for cache clearing.
Has any one ever done the math? Has any one actually thrown together the necessary code and given it a whirl to see how long it took?
Maybe this is one way EAC does it- I have heard reports of it "grinding away" and this would explain the grinding!

I will be happy to run some tests and see how long things take- but from my experience with the comparison ripper, reading 2 MB worth of data (at max speed) takes around 1 second. So assume 1 second for the cache clearing/flushing and about 1/2 second for reading each sector (I'm assuming the overhead of positioning the drive for reading, etc. is the limiting factor here). If an average track of around 5 minutes is 23,000 sectors, and each sector is read on average 3 times, that would be 69,000 sector reads. So for this, the sector reads alone would take over 9 hours! In all likelihood a sector read would take much less than 1/2 second; assuming 1/4 second the read time would be reduced to 4 hours (!). So, on paper, this sounds asinine.

Obviously paranoia reads one sector at a time, and it doesn't take 4 hours to rip a 5-minute track. Even with a drive that doesn't cache audio, there is no way things are that slow. I seem to have no free time at all for coding lately, but when I have some I will run a few tests since these numbers seem ridiculous.

Posted: Fri Jul 21, 2006 1:53 am
by Fuga
AGH! Yeah, thosee figures are absurd. I've used EAC extensively and grinding away never took all that long - easily as long as the playing time in minutes, never for so long I thought to time it.

one more question

Posted: Fri Jul 21, 2006 2:21 am
by mieler217
wow. this post has gone well over my head. i appreciate all the replies.

i guess i'm still wondering which program copies the source cd best. i've used max, itunes-lame, and nmp3. i'm totally comfortable at the command line, so that's not an issue (i like the size and quality of '-V 2 --vbr-new'). i would like to be able to swap versions of lame, but if someone can explain why 3.97b is better than 3.96 (besides that fact that it's newer), i might switch. the only reason i like 3.96 is b/c i've been using it for a while now and am happy with the quality.


thanks again!
mike

Posted: Fri Jul 21, 2006 2:44 am
by Fuga
As long as you're wanting to apply switches in your own statements you will have to use something other than max. It doesn't work of an executable version of LAME. Instead it uses "Libraries" (at which point I'm lost).

Try Max as is. Play with the settings and report back. As I posted earlier, I have not made the switch to Max for LAME yet. I believe I will eventually because the idea of loading a CD and after hitting a couple buttons having the CD ripped securely, with FLAC files and MP3s all coming out, is appealing. This is Max's promise. Scripting it all with current tools is too beyond me.

Posted: Fri Jul 21, 2006 6:45 am
by krmathis
mieler217 & Fuga. I found this information in the MP3SettingsSheet.m file (source code).
Which lead me to believe the "Transparent" setting use '-V2 --vbr-new':

Code: Select all

Quality 40, Fast mode (-V6 --vbr-new) (~115 kbps)
Quality 50, Fast mode (-V5 --vbr-new) (~130 kbps)
Quality 60, Fast mode (-V4 --vbr-new) (~160 kbps)
Quality 70, Fast mode (-V 3 --vbr-new) (~175 kbps)
Quality 80, Fast mode (-V 2 --vbr-new) (~190 kbps)
Quality 90, Fast mode (-V 1 --vbr-new) (~210 kbps)
Quality 100, Fast mode (-V 0 --vbr-new) (~230 kbps)
LAME 3.97b2 is the recommended version at the Hydrogen Audio community, where the LAME developers also hang around. The HA forum is highly respected for having serious users who perform listening tests before they give out any statements about sound quality for different encoders and settings.
Their previous recommended version was 3.90.3.

I suggest you start here: http://wiki.hydrogenaudio.org/index.php?title=LAME
Then move on to their MP3 forum for more information: http://www.hydrogenaudio.org/forums/ind ... owforum=55

Posted: Fri Jul 21, 2006 6:24 pm
by Fuga
many, many thanks, krmathis. just this morning I had surgery on my knee (scoped it, no big thiing at all) and now have an excuse to be totally worthless and can delve into some tings.

3.90 was what I had substitued into iTunes-LAME.

Posted: Sun Jul 23, 2006 3:34 pm
by danco
Max is an excellent program, one of the near equivalents to EAC for the Mac.

Another free possibility worth looking at is iTunes to cdrdao. Despite its name, it can rip a CD to a .bin image file and then burn a CD from that image file. It is available at
http://scriptbuilders.net/files/itunestocdrdao0.11.html

I haven't decided which I prefer as yet, I am evaluating both. I am inclined to think that for pure ripping and burning, iTunes to cdrdao is best, while for encoding and tagging the choice is Max. YMMV.