I'm using Ubuntu now, but EAC is Windoze only. Is cdparanoia up to snuff, or is EAC better to use? If so, should I install XP on another partition and dualboot, or use Wine?

Also, I need a FLAC -> MP3 solution. I was using Foobar2000, which worked very well, but that's once again Windoze software. I now use a script called "audio-convert" that works, but it's very irritating as I have to type in each tag by hand with it (and for some reason that didn't work, so I had to re-enter each tag with EasyTag).

If you have a drive that doesn't cache audiodata, cdparanoia should basically be as safe as EAC. But if you have a modern drive with a large cache, cdparanoia will only read the data twice from the cache, and no error correction will be performed (so it will be no more secure than just any ripper).

Cdparanoia development have been stalled since 2001. It's a pity that atleast some updating to modern drives with large cache can't be done to make it usable with new hardware.

abcde is a full featured command line ripper for Linux, although it uses cdparanoia which is still not as secure as EAC, also grip is a popular one

It is possible to run EAC under Linux using wine, which is a compatibility layer for windows, but it's a little hard for a novice to set up correctly (Ubuntu might have a package for it that's preconfigured for proper cd-rom access though)

Dual booting sounds like a clever way to do, provided you can afford a Windows licence.

Maybe you can find someone who upgraded to XP lately. Maybe he has a spare Win2000 CD, which is a fine OS BTW.

I have XP, but I don't really want to have to dualboot in order to rip CDs. I've installed Wine, but I can't run EAC:

Foobar and EAC are the only two reasons I begrudgingly came back to windows. Linux is very poor where audio software is concerned.

In simple words-No!

Its open source - just need someone with the talent and the desire to do so.

Yes, I know. The golden Q is: Who?

Monty has said in the past that patching cdparanoia would be a simple job. Search for one of my posts and look for its parent post.

http://slashdot.org/~kjoonlee/

And look at what pjones (the maintainer of RedHat's cdparanoia RPMs) said in a recent Xiph Monthly Meeting:



Oh, if you ask me why it hasn't been done if it's so simple, I can only say I don't know.

I think there is more to cdparanoia's problems than just the caching issue, since with my drive (Plextor PlexWriter 12/10/32A) using EAC if I disable the option to disable cache, I can get a perfect rip (test & copy CRCs match), but for the same track using cdparanoia the files DONT match.

What I do find works, as cumbersome as it is, is to run Windows in a vmware box, and run EAC or PlexTools inside there... not a very good solution, but it works.

Did you compare the raw PCM or did you compare the .wav files?

I used EAC's test and copy routines to compare using EAC, and I used md5sum on the wav files ripped by cdparanoia.

I was testing only two rips from the same program... in my mind if you rip the same thing twice then it's most likely correct.

No wonder it didn't match. The md5sum of the .wav file depends on more than just the PCM data. In case you used offset correction with EAC, then you should have used offset correction with cdparanoia as well.

You should have used EAC's "Tools -> Compare WAVs..." feature or something similar.

edit: Or am I misunderstanding you?

Make sure to use IDE-SCSI emulation, you need it for EAC to detect your drive. It must be enabled in your kernel, and you must boot using the following kernel argument: hdc=ide-scsi
Replace hdc by the device matching your drive.

How exactly do I do that? I'm fairly new to Linux.

I wasn't comparing the rips between EAC and cdparanoia, I was comparing two consecutive rips from the same program.

That is....
I do test and copy in EAC and see that the CRCs match, therefore I am confident it is a good rip.
Then...
I rip the same track using cdparanoia twice, and do an md5sum on both of them, and find they don't match, therefore I am fairly confident that it is NOT a good rip.

HowToEnableSCSIEmulationWithHoaryKernel26 - Ubuntu Wiki

Sorry resurecting an old thread I never got around to reading, I vehemently disagree with that comment though . In fact I think Linux audio software has come a long way in the past 5 years with ASLA Project, Open-Source Sequencers, editing tools and it's own alternative libraries like JACK, LADSPA, DSSI, etc. Why not just run Wine if one is not satisified?

What exactly is your argument? Is there anything like EAC or foobar2000 on Linux?

No.

So what are you jabbering about?

If you want to use Windows software you might as well use Windows instead of messing with Wine.

Well, EAC needs SCSI emulation and it is kinda bothersome but Foobar2000 runs quite nicely with wine. In fact I still have found no Linux replacement for either

Once again bringin this from the dead, but..

I recently got Ubuntu up and running, and the commentary you made about anything like foobar on Linux, it's just wrong. amaroK is quite nice and brings many of the features we are still waiting foobar .9 to port. I also tried grip, and testing with my er6 and Grados SR80 lead me to believe both EAC and Grip rip the same thing at the same size.

There has been some nice piece of news since : EAC does not need scsi emulation anymore. Well, it is probably not the solution, still, it performs nicely.
[edit:]spelling

I've just install wine and EAC in the latest Ubuntu. Seems that wine now has an ASPI layer.

It works!

Except it doesn't detect any audio CD, which I think is because it can't find my cdrom drive.

Has anyone got it working?

cd ~/.wine/dosdevices
ln -s /mountfolder z:

makes folders available as a drive (Z: in this case)

or try "winecfg" command if you prefer GUIs.

but i don't know if this works for EAC.. no linux here atm

So it works, but it doesn't?

for a howto: http://ubuntuforums.org/showthread.php?t=142784 - I haven't tried it yet; since most discs I have are in brand-new condition, I just use cdrdao to rip twice and compare with cmp. [edit - removed complicated statement] It's as good as a single run in EAC, something like test and copy in synchronized read mode[/edit].

If I should come across a disc that doesn't give the same result twice, I'll have to decide what to do then... probably I'll read that how-to and install EAC

[edit2] You could also have a look at rubyripper.

Thanks for the replies.

That looks awesome. Nice way to get around CD paranoia being unable to turn off the drive cache.

I followed the guide on Ubuntu forums, now EAC just locks up when I change the interface from ASPI layer to Native.

I think I'll try rubyripper, accurate rips in linux is all I'm after and that will do the job perfectly

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".

Their commentary was not wrong at all. amaroK cannot be called ''like foobar2000'' just becuase it shares some (a small portion) of the same features.

WTF? For Pete's sake, would a moderator please send this nonsense to the Recycle Bin !?

Once again bringin this from the dead, but..



I honestly can't tell the difference myself. It's all about the drive anyway. If the drive doesn't do C2 error correction, forget it. I care that the rip is accurate to an extent, but if it's not bit-perfect I am not going to loose any sleep over it. They are probably not exactly the same, but what the heck.



I think in all fairness it's good to finally see some other rippers that can do secure extraction. OS X and Linux users shouldn't be left out to dry.

The whole reason for accurate ripping is that you don't want to have to check your whole rip for errors by listening to it. You don't want to find out there's an error in it after you've done all the encoding etc. The problem with almost-perfect is that the difference might well be very audible. An accurate ripper saves time in the end.

I understand what you are saying. Here is my personal experience from using EAC. I got horrible results. I had a CD that, because of my damn fault had scratches on it I will admit to that. The only feature my CD-ROM drive has is Accurate Stream with NO C2 error correction. I sat there for a half-hour letting EAC chew away at my drive and in the end even with all of the error corrections I still got pop / clicks in the output. I tried to deglitch the samples using David Bryant's utility no luck. I don't know exactly, if cdparanoia checks for C2 errors. I am going to assume it doesn't, but on low-end CD-ROM drives in the past it has done a great job dealing with jitter and error correction, interpolating the samples, etc. It takes half the time and rarely did I have any audible problems if any at all. That was only one disc. I am not saying it's better, that's just my experience. Again it comes back to the drive that's what I have learned. People need to take better care of their CD's too haha.

http://www.hydrogenaudio.org/forums/index....ter&f=20&t=3164 just so I don't look like the bad guy here. I am not the only one with this rational at least ;D

I think this is a known fact... on damaged discs, some transports do better in continuous bursts of reading. You can do that with EAC too (see below).


It doesn't do C2 error detection as far as I know, nor does it interpolate for you. I think cdparanoia is about the same as EAC in synchronized read mode.


I'm not sure what you mean? That message says that EAC does a lot better than cdparanoia, right?

Anyway, my earlier post was just a reply to your point that it's fine if the rip is accurate to a certain extent. I'm saying that doesn't make sense... there's no such thing as a "small error" in ripping. Even if it's a single bit, that's quite significant if it's the most significant bit
That EAC can't rescue each and every disc is not the point

Given the fact that some discs have unrecoverable errors, some people prefer that a drive have the ability to conceal these errors. Some drives do a better job of this than others.


This is a mischaracterization. You can't talk about significant bits as the pits and lands on a disc don't represent individual bits of samples, they represent symbols which must be decoded in oder to get audio data.


Despite what is seen on the GUI, EAC does not perform error correction, it simply asks the drive to re-read data.

I'm afraid I'm missing the point here... true, bits are encoded in sequences of pits and lands. There's something like a 14-to-8 mapping, etc. But all that does not mean I can't talk about significant bits. The bits that end up in my pcm data when ripping certainly have a hierarchy of more and less significant bits.

Sure the bits that end up as your pcm data have a hierarchy as you pointed out, but to suggest that a sample's amplitude gets botched by a single bit seems like an oversimplification to me.

I will admit that it has been many years (~10) since I've studied this stuff in any great detail.

Besides this, I think the point is that not only do audible errors depend on a disc's condition, but they also depend on the drive doing the extracting.

Speaking of drives as they relate back to the subject of this thread, if they cache audio data and you don't have a program that works that can correct this shortcoming in Linux (or on a Mac OS, for that matter) you're at a real disadvantage.

Has cdparanoia dealt with this issue yet?

yes exactly



Yes as I was pointing out drive is the key factor here . Some folks are working on their own methods for dealing with that. Again I really don't see the difference if you end up with the same audible errors and I prefer not to play around with burst-mode.



No it says nothing conclusive can be reached about the difference between the both of them with exception to that Memorex drive. The output is less noiser to then with EAC, despite the fact that EAC detects more errors.

The so-called "most significant bit" contributes one-half times the full-scale signal, so it's perfectly possible. Typically a scratched disc will ofcourse give more than a single error, I was just saying that even a single-bit error can be enough to wreck the sound (imagine what a single-sample jump of 0.5*FS might look like in the frequency domain ).


No, cdparanoia hasn't seen any changes since 2001 (that's what it says on my system, and I'm trying to have the latest packages). That rubyripper script circumvents the problem in a simple way: If you read a whole track, then reread it from the start, the cache will certainly have been flushed
It's just a bit slower on errors... if, say, there's only one sector damaged, the script will still keep rereading the whole track.
In general, my opinion is that this method is better than EAC's if you're worried about wearing out your transport; EAC sends the pick-up seeking back and forth over every few sectors. Ofcourse, what rubyripper can't do, and EAC can, is tell you where exactly the errors are.



Aha, I see what you mean. Still, I would prefer EAC in this case, because it at least tells me there are a lot of errors.... so then I can go and find me a better copy of the disc (not a copied copy... - is there a better word for "copy" in this sense in English??).

The worst thing about cdparanoia that hadn't noticed before is that there is no API or documentation for it. I would elect myself to write it to get things up to snuff, however I don't even know if the source code is readily avaliable. Some programmers have the time and energy to write it, however most of them are so lost in there code they forget to write the documentation or API. It's either that or they don't want to take the time to do it at all. This is why companies hire Tech Writers. Anyway after my usual ranting

"man cdparanoia" doesn't give a man page? I thought it did, can't check at the moment though.

Kristian

As kritip says, there's a man page, And the source code is available from just about every Linux distribution, and from the xiph project, to name a few places. Don't rant, search.

Someone from redhat made some patches to include sgio support, which makes usefull for caching drives. At the time (a year ago) there was nothing that would do what eac would do (i especially missed test&copy and logging), so i went on to make a script to automate the entire process of ripping a cd.

When reading a damaged disk, a good sofware is important as is the drive IMHO. Lower reading speed is often better when reading scrached disk. That's why the EAC detect's errors so it can lower the reading speed. It's bad when audible errors occures, but still, I choose less noisy output. I have done some test's, and for me and my drive, EAC is better than cdparanoia or CDex. I'm not saying that EAC is alwasy better, but in my case, it's better more often.

That's brilliant! Should be the name of this subforum

The more you deal with audio and music, the more you leave linux. Especially when it comes to audio production, linux is dead. And we have no eac for linux. No nero aac encoder yet. We have no fb2k. no samplitude. no fl studio. no fancy vsti/fx. no nothing. So if possible I'd always set up a windows machine.

That's a bunch of bullshit. There are plenty of audio protocols on Linux that have readily impressed me. Linux has some great alternatives. If you are looking for MIDI sequencers check Rosegarden and MuSe. There is Nero Linux also. You don't need EAC for Linux. These people who run this goddamn Wine Layers so they can play around with EAC are streadily wasting their time.



No there isn't. If this is what you are referring too... http://www.xiph.org/paranoia/prog.html. I hadn't realized that the source-code came with packages though my error. I thought it was just the binary

This was not directed at me, but still - no need to be rude. This is not slashdot.



http://manpages.debian.net/cgi-bin/display...67&format=plain
Don't rant, search.

No this is the manuel. You guys are misunderstanding what I am getting it. I am talking about the API documentation for programming with cdparanoia. I understand the manual is readily avaliable. Notice I CLEARLY stated that when I started talking about it in the first place to begin with.



I wasn't being rude at all. That person was making a bold and naive comment in my own personal opinion. I apologize for being condscending, I was trying to make a point. I am not here to offend people or pick a fight. If anything I am here to help out in any possible way. I hate arguments that are inconsistent or fail to provide any logical information (granted opinion can get in the way of things often)Anyway let's get back to focusing on the topic. Yes people are rude on slashdot.

HotshotGG:
How is one with a drive that caches audio data able to identify errors and where they are in order to attempt recovery without using EAC?

Patsoe:
As far as minimizing excess wear and tear, EAC can rip in burst mode and check test and copy checksums.

I am uncertain about that, especially with cdparanoia (I am inquiring about that) was it purposly designed that way?. I never understand what the argument is here. I have asked for clarification about this numerous times, why exactly you do or don't need a drive that caches? maybe I am still misunderstanding something. This is why I am interested in other algorithms, etc. I understand the point for using EAC, but people are very quick to write off any other possible ideas about this, that and the fact that for somebody new EAC is a nightmare to configure.