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: To make new Secure CD-Ripper (Read 9345 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

To make new Secure CD-Ripper

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

To make new Secure CD-Ripper

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