Hi,

I'm on a Mac and am not quite sure the only "secure" ripper for Mac OS X, Max, is indeed secure enough.

I have read a lot about EAC and dbPoweramp in this forum and cannot make up my mind which one to use on my Windows partition on my Mac. From what I understand there are pros and cons with each program. EAC has this feature Burst T&C with AccurateRip which sounds appealing. The problem is that (and again from what I understand) AccurateRip rarely recognizes any other discs than US pressed ones.

Instead if I wanted to use EAC's secure ripper but utilize dbPA's excellent tagging features - read AllMusic Guide - plus the ability to write to AIFF instead of WAVs, can I somehow in EAC's setup (or dbPA's for that matter) choose either program as ripper/transcoder?

(The inability to write to AIFF instead of WAV is a major drawback of EAC's in my view. I have heard of iTunes Encode but that seems a bit fiddly - or am I wrong?)

Would be grateful for any advice.

Nubben

As long as you use AccurateRip with either EAC or dbPa you are 99% of the way there. As for the AR database being primarily US pressings (and I don't know if this is correct), this will continue to improve if people like yourself add other pressings for submission.

When I first started using AR there were only a few hundred CDs in the database (Spoon had to send me some so that I could determine my offset). I then ripped my entire collection so that those CDs could be used by others as reference, and so on. No database is perfect in the beginning, and the AR database will never have absolutely every CD ever made, but the more we use it the better it gets.

Two things regarding dBpa and burst test & copy:

1) If you have dBpa configured to perform at least two passes (C2 disabled, or C2 enabled with at least one Ultra Pass) it performs burst test & copy as a normal mode of operation. If AccurateRip is enabled and the first pass generates a match then the rip will stop at that point since the second pass won't be necessary.

2) dBpa also has a functionality similar to EAC's test & copy in that you can rip something twice and verify that the CRC was the same the second time around. In the case of EAC, you see a CRC in each column in the GUI and there's a third column that indicates whether they are the same or not. In the case of dBpa, there's only one column that displays a tracks CRC. If the track was ripped again and the CRC was the same it will be displayed in green. If the CRC was different it will be displayed in red.

dBpa can rip to AIFF with an addittional codec. You can use sox to convert to AIFF using EAC, but it will not rip to the format directly. iTunesEncode may be able to enable you to convert to AIFF as well, I've never used it. Any reason why you don't want to use Apple Lossless instead?

@pdq: Yes, I agree, more users and the database will grow. Hopefully I will be able to use some of my own discs to set up the process properly.

@greynol: Thanks for your explanatory answer. Will try both options. I normally rip directly to Apple Lossless having used Max on my Mac and will convert AIFF from EAC/dbPA in iTunes. Maybe I'm wrong here but I just trust Apple's codec more than a reverse enginereered one. Or am I wrong there?

Also @greynol: I have read several of your posts in this forum and you seem very knowledgeable. I have just purchased a Samsung drive which according to one Hydrogen poster doesn't cache audio and support C2. In your view, what would be the best solution? If I remember correctly you favor EAC with T&C in burst mode. Is that correct?

I think the best option is to use the drive's C2 pointers with dBpa (it sounds like you plan on buying it anyway, no?).

I am primarily an advocate of Burst T&C in EAC for people with caching drives, though I actually recommend copy (F5) check AR results and then test (F8) the tracks that can't be verified. If you were to use this drive with EAC, I would probably recommend Secure mode with C2 pointers and without cache flushing (assuming it doesn't cache) with F5-AR-F8(if necessary), or do what Jean Tourrilhes suggests by ripping in Secure and test in Burst if AR can't verify your rip.

I understand your concerns about reverse engineering ALAC. I don't have any personal experience with or read any comments about Spoon's implementation of ALAC to say anything meaningful. I do know he's expressed concerns about the SDK for WMAL but that's obviously not the same thing.

I think you will be even more impressed with PerfectMeta in R13 of dBpoweramp.

dBpoweramp, in secure mode, is at least as good (even better w/ C2) as EAC.

Not without C2 pointers it isn't.

http://www.hydrogenaudio.org/forums/index....st&p=558028

Depends on the drive, there is code in there with rolling read addresses, to try to defeat consistant errors, which worked well on a drive without c2 (if you were to refer to the original test I did), not saying it will work on all drives, but consistant errors are the ones where extra work has to be done to defeat them, rather than a simple read re-read re-read...

I see you've changed the presentation around a bit.

Could you point me to which drive and on which tracks this additional code proved useful?

It was the Matshita - UJDA757, tracks 8 and 9, those 2 had consistant errors which EAC did not report.

Thanks. You may want to mention that in a remark in order to highlight your additional code.

Thanks everyone for all your help - very much appreciated!

greynol and spoon: Couple of further questions if you have the time?

1. Since the drive I just bought does not cache audio - would cdparanoia be a valid option as well? Max, the Mac program, uses that. Problem is that Max doesn't have any error reporting - only that a track ripped ok. I do appreciate you're not a Mac expert (or maybe you are?!).

2. When you say "AR" - what does that mean?

3. The AIFF codec supplied with dbPA - is that simply decoding the wavs to aiff or is that codec transcoding to aiff? Again, it's my being cautious re reverse engineered codecs.

4. One way of getting around all of this would be to rip to a cd image using EAC or dbPA. I would then log back on to my Mac OS X system and let iTunes rip the CD which I had mounted on my desktop. Could I achieve this by creating an .iso file and if so, would EAC or dbPA be able to create such a mountable image? Can I create an uncompressed image so iTunes will recognize it? (iTunes, of course, cannot read flac files.)

Sorry about the myriad of questions. Just eager to get this set up with a nice workflow so future ripping will be as streamlined as possible.

Nubben

AccurateRip

AIFF and Wave are uncompressed, there is no encoding to be done.

spoon: Thanks for your reply. So the AIFF codec you're using is open source or ar eyou using QuickTime's?

Nubben

We use our own. Generally speaking, our codecs have such high usage we are notified very quickly if there are any issues.

Ok, thanks for your replies Spoon.

Regards to my Q on ISO images - is that something dbPA can accomplish?

Nubben

.iso images are for data cds.

1) Max should be secure for non-caching drives. If it isn't then it isn't secure for non-caching drives then it won't be secure for any drives.

3) There is nothing to worry about when it comes to ripping to AIFF. As an uncompressed format there's really nothing to "reverse engineer".

.iso images can be used with audio also. This isn't something that's typically done on a Windows machine, though.

...or am I getting this mixed up with .bin files that can be used with audio?

Many thanks greynol/spoon.

greynol: The Samsung SE-S204N I just purchased does not cache audio so that's good. I think if I can stick with Mac OS X that would be more convenient so if you say cdparanoia is ok then I will try that. Thanks again for all your help - truly appreciated.

spoon: When I run both EAC and dbPA through VMWare Fusion virtual machine dbPA recognizes the Samsung USB drive but says there's no audio CD in the tray (when actually it is). Have you come across this before?

Nubben

Virtual machines cannot access the cd drive direct enough to do ripping (atleast when I have tried).

Thanks for that Spoon.

One final question if you have the time - I will rip my CDs to individual tracks instead of images now and don't care very much for gaps etc. Is there any way to not append gaps to files, that is can I change it in dpPA's settings?

Many thanks again for all your help.

Nubben

You may be confused about appending gaps. For example, when I use dbpa to rip my CDs, if the CD is a gaples s CD (e.g., a Pink Floyd or the Beatles Abbey Road), the playback of the ripped files is in fact GAPLESS (both the FLAC and the mp3 (lame) files I create. So appending GAPs does NOT add new gaps that were not there in the original CD. Bottom line: My ripped individual tracks play back identical to the CD. If CD is gapless so are ripped tracks.

Thanks garym. However, when I have decoded FLAC/APE image files using a utility on my Mac called XLD it gives me the option to include or exclude pre-gaps. I would like to exlude this extra "silence" (although there might be data there) if it's not audible.

So what you're saying is that pre-gaps will only be an issue if I decode or rip to an image?

Nubben

I can't comment on XLD, but if these images were ripped from an original disc, the "gaps" are part of the disc and aren't necessarily silence. Even if they are silence they certainly aren't "extra" silence.

"Welcome back" greynol! Thanks for your reply.

(I know we're deviating a bit from the original topic...)

I have read that EAC lets you tinker with the pre-gaps to include or not include. Since I rip to individual tracks mainly for my iPod I would prefer if a gap of say 5 secs was no appended although it is part of the structure of the CD. I want perfect rips in terms of sound - not so much "an identical copy" of the disc's structure.

I know you have commented on pre-gaps before and stated one should leave them in because they're not "silent" as such - they do contain audio (?).

As an example of ridicilous gaps I have a CD of the Swedish group KENT where there's a 20 min silence b/w the last track and a hidden track towards the end (all part of the same song. I took that track and broke it up in two tracks deleting the long silence b/w them. Instead of 12 tracks the ripped CD ended up having 13 tracks. So, I'm not too concerned about an exact copy of the CD.

So, it would be nice to be able to turn off this option in dbPA (since I'm buying that program). From what I understand EAC has this option.

As usual - really appreciate your input.

Great forum.

Almost all gaps are 2 seconds, like Greynol said, on most (?) CDs this is actually audio, the studio engineer tends to just apply a large gain adjustment, so it is not quite zero.

We have DSP effects to remove 'silence' from the end of audio files, silence is in quotes as it is not always silence.

About the last hidden track, AFAIK there would be no pregap info for that track as the hidden track is at the end of the last track, again for DSP Effects R3 we have an effect which can remove the large in track silences, especially for these hidden last tracks, we also have an effect to remove the small silence tracks (think Nine inch Nails), where you have 80 tracks of 3 seconds of silence and a last 'hidden' track.

Tx spoon!

I assume I'd apply these DSP Effects after I have ripped the CD? Is this the "Trim Silence" feature?

Nubben

I don't use this DSP effect, but I often use DSP effects as part of the ripping process (see the bottom DSP tab in the middle of the CD ripper program near the bottom). For example, I use replaygain and ID tag processing here. So this all becomes part of my ripping process automatically.

EAC has a test gaps for silence feature, which you can use to determine whether you want to keep them or not. A peak level of 0% does not distinguish between pure digital silence (null samples) and low level noise, but based on what you're saying this shouldn't matter to you. Still, this does not guarantee that the gap contains all the silence you wish to discard.

EAC also has the option to delete leading and trailing silent blocks, but this time the silent blocks must contain nothing but digital silence for this to work.

...it could just be noise from the source tape (low-level noise which I would still consider as silence, just not digital silence/null samples/samples with zero amplitude). The gap could also contain audible sound that may result in a track ending abruptly if left out.

Spoon - have you tried the direct-USB support in VMWare (they may even have direct-firewire now), or just the standard optical-drive support (e.g. connect the d:\ drive)?

Note: my experience with VMWare Workstation has been positive with the direct-USB support in the past, but I never tried audio ripping with it.

-brendan

No, never tried direct USB.

Thanks greynol/spoon/garym and everyone else for all your help.

Nubben