Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Is any Linux ripper as good as EAC? (Read 39364 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is any Linux ripper as good as EAC?

Reply #25
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.


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.

Is any Linux ripper as good as EAC?

Reply #26
[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 

 

Is any Linux ripper as good as EAC?

Reply #27
Nice way to get around CD paranoia being unable to turn off the drive cache.

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

Is any Linux ripper as good as EAC?

Reply #28
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 [..]
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.

[..]  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.
WTF?  For Pete's sake, would a moderator please send this nonsense to the Recycle Bin !?

Is any Linux ripper as good as EAC?

Reply #29
Once again bringin this from the dead, but..

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


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. 

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


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. 
budding I.T professional

Is any Linux ripper as good as EAC?

Reply #30
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.


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.

Is any Linux ripper as good as EAC?

Reply #31
Quote
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
budding I.T professional

Is any Linux ripper as good as EAC?

Reply #32
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 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).

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

Quote
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'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

Is any Linux ripper as good as EAC?

Reply #33
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.

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

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.

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.

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

Is any Linux ripper as good as EAC?

Reply #34
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.


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.

Is any Linux ripper as good as EAC?

Reply #35
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?

Is any Linux ripper as good as EAC?

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


yes exactly 

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


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.

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


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.
budding I.T professional

Is any Linux ripper as good as EAC?

Reply #37
... to suggest that a sample's amplitude gets botched by a single bit seems like an oversimplification to me.

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

Quote
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?

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.

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.


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??).

Is any Linux ripper as good as EAC?

Reply #38
Quote
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


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 
budding I.T professional

Is any Linux ripper as good as EAC?

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

Kristian

Is any Linux ripper as good as EAC?

Reply #40
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.


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.

Is any Linux ripper as good as EAC?

Reply #41
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.

Is any Linux ripper as good as EAC?

Reply #42
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.

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.


Is any Linux ripper as good as EAC?

Reply #44
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.

Is any Linux ripper as good as EAC?

Reply #45
Quote
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.

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


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
budding I.T professional

Is any Linux ripper as good as EAC?

Reply #46
That's a bunch of bullshit.

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

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


No there isn't.


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

Is any Linux ripper as good as EAC?

Reply #47
Quote
http://manpages.debian.net/cgi-bin/display...67&format=plain


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.

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


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.
budding I.T professional

Is any Linux ripper as good as EAC?

Reply #48
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.

Is any Linux ripper as good as EAC?

Reply #49
Quote
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?


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. 
budding I.T professional