New Open Source Secure Audio CD-Ripper
I'm a big fan of EAC (http://www.exactaudiocopy.de/) and have used this ripper for many years now. I started to use it when it only was v0.8beta. Now I would like to make my own ripper.
I would like to know if anybody was interested in an Open Source (http://www.opensource.org/) ripper. And it was as secure as EAC. I would like to program this, but I'm only proficient in Sun's Java (http://java.sun.com/). This is why I would like anybody who can make a wrapper class to Adaptec's ASPI.
It would be great to have a ripper capable as EAC (http://www.exactaudiocopy.de/), defeats copyprotections and is OS (http://www.opensource.org/). If anybody is interested in this, please post.
Well, I would say I am interested.
Every bit of open source software I have seen rapidly becomes the best there is. EAC is superb software but it can't be improved by anyone who wants to throw their hat in the ring.
An open source architecture would assist in the rapid defeat of the various copy protections that are restricting fair use rights.
$.02
I'm very interesed, too!
Every bit of open source software I have seen rapidly becomes the best there is.
Really? The best ripper is not open source (there was a thread here comparing EAC vs. CDex, and there was no competition), the best lossy codec is not open source (except for MP3, see Roberto's tests), and definitely the best player (as in most feature-packed) is not open source.
I'll give you the best web browser, but that is pretty much it.
Sometimes OS approach hurts development-focus. But that is just my opinion. I don't want to turn this topic into yet another Open vs. Closed source kinda thread. I welcome you efforts and wish you luck. I just don't hold instant high-hopes for every new Open Source project.
I'm not sure I'd want to use a ripper written in Java. Its fun for programming projects, but its unpleasant to use for applications.
I'm a total n00b when it comes to programming, but does it truefully matter what it was coded in when you are given a working executible? As long as it works it could've been coded in klingon for all i care
Did you read this thread ?
http://www.hydrogenaudio.org/forums/index....howtopic=17170& (http://www.hydrogenaudio.org/forums/index.php?showtopic=17170&)
Actually after the previous cache discussion on this board I considered writing a
new "secure mode" for CDEx (cdparanoia recovery code is too messy for me). Something
more urgent came on my way but if I have time next month I'll contact CDEx maintainer
and discuss it with him.
Maybe Spath would be interested in your project too.
Java ist spoony.
Seriously, i wouldn't use a ripper coded in Java.
But the idea of an opensource ripper isn't bad at all.
help cdex to become better than eac
help cdex to become better than eac
I agree. CDex is already Open Source, and from my experience Faber is always very willing to welcome skilled developers to the project (and some not as much skilled, like me ). It already has a functional interface, API hooks to most encoding DLLs, Winamp plugin support ( ). Why start from scratch, when you can just add a new secure reading mode to it?
help cdex to become better than eac
agree
I'll give you the best web browser, but that is pretty much it.
I personally think that is quite arguable. (But I'm a die-hard Opera fan )
One open souce app that can be considered quite better than all the closed source competition is Apache. The numbers (http://news.netcraft.com/archives/web_server_survey.html) speak for themselves.
How about incorporating the paranoia library into CDex?
Is paranoia comparable to EAC in terms of security?
How about incorporating the paranoia library into CDex?
Is paranoia comparable to EAC in terms of security?
hehe.. paranoia IS part of cdex... and no its not compareable sadly, otherwise i'd be on linux for long now
How about incorporating the paranoia library into CDex?
Is paranoia comparable to EAC in terms of security?
Paranoia is already in CDex.
EDIT: N/M Someone Beat Me .
I thought paranoia routines were already in cdex. I think it's widely accepted that eac secure mode is better than paranoia.
We recently have seen the power of the community showing its appreciation with a little financial support for developers. Maybe Andre could be approached with some funds to buy the source for EAC for the open source community. While he is still very active in the support there hasnt been much development. Plus open source would allow the addition of things like TOC correction, which Andre had to drop.
Paranoia is good, actually. But it won't help you at all with drives that cache audio data. It's its biggest weakness.
We recently have seen the power of the community showing its appreciation with a little financial support for developers. Maybe Andre could be approached with some funds to buy the source for EAC for the open source community. While he is still very active in the support there hasnt been much development. Plus open source would allow the addition of things like TOC correction, which Andre had to drop.
Andre's main argument for not opening the sources is because he plans to make a library out of the extraction routines and sell it as a SDK. Open sourcing it, no matter what license you use, would defeat that purpose.
And, even considering the donations from users might be enough to convince him to give up the SDK idea, there's another very big problem: It's coded in Modula II (a quite obsure Wirth structured language). That introduces several problems:
- The compiler Andre uses - Stony Brook Modula II - is commercial and quite expensive, $495 last time I checked it. Besides, Andre uses a version not available anymore, so his code would need to be adapted to the current version in case there are compatibility issues.
- Being an obscure language, I guess few people have the knowledge to comfortably code in it, let alone tweak Andre's code (he admits the code is a mess, with no order or comments)
- Porting it to a more popular language like C would probably be such a big effort (again, because the code is badly structured and commented, and because there are probably too few or no Modula II programmers around wanting to take such project), that starting another ripper from scratch would probably be easier and cleaner.
rjamorim
thanks for the reply. I know he had plans for a commercial SDK but those "plans" have not given way to much in >2 yrs to my knowledge. Talking with Andre its his dev tools that put alot of limits on what he can do with EAC. He knows the routines and the ins and outs of audio extraction, maybe its time to try to recruit him to build and open source C++ tool, Im not holding my breath, but it would be nice...
maybe its time to try to recruit him to build and open source C++ tool
He's not even working on his own app (much), let alone start a new routine from scratch in another language
I still believe your best bet would be trying to improve CDex.
maybe its time to try to recruit him to build and open source C++ tool
He's not even working on his own app (much), let alone start a new routine from scratch in another language
I still believe your best bet would be trying to improve CDex.
I agree with that, its open and already has alot of the ground work. I dont know if money would motivate him but his input with something like CDex would be invaluable.
It's worth noting that an open source effort, if written in C, could lead to ports to Mac OS X and Linux. Especially if the designers took this into consideration...
It's worth noting that an open source effort, if written in C, could lead to ports to Mac OS X and Linux. Especially if the designers took this into consideration...
CDex is written in C++. But lots of things would have to be adapted (DLL APIs, CD access routines, get rid of the Winamp plugins at last...)
It's coded in Modula II (a quite obsure Wirth structured language). That introduces several problems:
Modula-2!! Wow! I didn't think anybody used that since the late 80's.
Actually, if you know Pascal, M2 isn't that hard to deal with. Not at all like Ada.
And there are a number of free compilers for it. Plus some commercial ones that are free for personal use. Plus some opensource ones.
And there are tools that could help structure it and possible help convert it to C or C++.
M2 does still have its fans. (As does the successors Modula-3 and Oberon.)
So it could be done. Just a matter of him chosing to do it. And only the lower levels of the program would actually need to be coded carefully. The rest could be written in any language he wants. Even Forth or Z-code...
(For those who don't know, Forth is a stack based RPN language dating back to the 60's and Z-code is the assembly code used in the famous Infocom adventure games back in the 70's and 80's.)
Java ist spoony.
Seriously, i wouldn't use a ripper coded in Java.
But the idea of an opensource ripper isn't bad at all.
Why is the language java worse than modula that EAC is programmed with?
But if people don't like Java, and I would like to help. Then it's meaby time for me to become much much better at C/C++ so I can give a helping hand with CDEX. Eventhough that I would like to start from scratch.
Why is the language java worse than modula that EAC is programmed with?
The Java API has all kinds of limitations and issues. Look at all the hassle schnofler goes through to make ABC/HR java work well in several platforms.
And ABC/HR is fairly simple: WAV read, randomization, playback, encryption, and some GUI stuff (rankings, comments, test setup...)
Compare that to a full featured ripper: CD access routines, error detection, GUI, jitter correction, normalization, API hooks to encoding libraries, tagging, freedb, offset correction...
And can Java easily talk directly to hardware? (cache reset, detection of read routines, read retries, feature detection (Cache, C2, etc.), and so on)
The languages aren't THAT different - both are structured, at least - but while Modula II's compiler output is standard object code, Java's is pseudo-code that is supposed to run on every platform with a Java Runtime Engine. The limitations in Java come from that supposition.