Skip to main content

Topic: To make new Secure CD-Ripper (Read 7797 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Preuss
  • [*][*]
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.

  • rjamorim
  • [*][*][*][*][*]
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.
  • Last Edit: 23 February, 2004, 02:34:41 AM by rjamorim
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org