Progress of the next Exact Audio Copy, E-mail from Andre Wiethoff Options

[JeanLuc]

Over at the EAC forum some time ago, BobHere posted the idea of coding some kind of DAE post-processor which will apply advanced error correction algorithms in conjunction with an advanced logfile (which, on CU errors, exceeds even the Plextools' log regarding the grade of information detail).

His idea was that it should be able to:

1. emulate the more advanced error correction schemes many good standalones show when being compared with consumer-class players with a post-processor

2. after the DAE host application (in this case - EAC) encountered and thoroughly logged unrecoverable read errors.

This would be some kind of possible future outlook ... -

[JeanLuc]

PS- Does anyone know if it's possible to get EAC to create ~\<artist>\<album>\<nn><name>.mp3 format directories when it rips CDs?

Unfortunatly its not :-(

I also would love this feature

Erm ... EAC's filename creation options allow almost any filename/directory name composition ...

[fairyliquidizer]

Unfortunatly its not :-(

I also would love this feature

Erm ... EAC's filename creation options allow almost any filename/directory name composition ...

I'll try again but I couldn't get the directory bit to work. What do u use?

[deej_1977]

Unfortunatly its not :-(

I also would love this feature

It is! Please try searching the EAC boards before dismissing a feature as not there.

In the naming scheme, use "\" to have EAC create directories.

E.g. My scheme says "%C - %D\%N - %A - %T". This way I rip to a dir Albums and it automatically creates a folder "Disc Artist - Disc Title" where it puts the tracks in in the format "track# - trackartist - tracktitle". It works flawlessly. The only disadvantage is that it writes the .log files in the parent directory (and now I'm nitpicking, I know).

EDIT: JeanLuc was faster

This post has been edited by deej_1977: Jan 6 2004, 15:46

[spath]

@JeanLuc:
> Andre did some testing during the last weeks (including some methods of FUA
> implementation that did not work in the end so he decided to check how plextools
> handle caching issues) ...

More precisely Andre tried a few wrong methods which failed and concluded that FUA
bit doesn't work on Plextor IDE drives, then looked at Plextools and saw something
that he refused to explain, then called it 'Plextools method'. Why he didn't see
Plextools using FUA bit on his drive would be interesting to find out, but as usual
he didn't give any detail about how/what he tested. My guess is that what he calls
'Plextools method' is the fallback solution Plextools uses on drives which don't
support FUA bit.

> good "windows coder" (using your terminology, sorry for that but IMO he is
> a little more than a windows coder) that he is,

I didn't mean to be exhaustive, I just gave one thing he is and one thing he is
not. And he's definitely not an error correction specialist

> he claims to have found a way to implement the method used by Plextools into
> EAC ... we will see whether this works out or not.

Sure, with all the detailed explanations of Andre it will be very easy for
everyone to see if this new algorithm is better or worse than the previous one

> Over at the EAC forum some time ago, BobHere posted the idea of coding some kind
> of DAE post-processor which will apply advanced error correction algorithms in
> conjunction with an advanced logfile (which, on CU errors, exceeds even the
> Plextools' log regarding the grade of information detail).

Best luck to you, but error correction cannot occur outside of the drive.


@westgroveg:
> spath, you seem to be very knowledgeable, why don't you create a library of
> error detection & recovery methods for CD audio? or maybe add to the cdparanoia libs?

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.


@Halcyon:
> while I appreciate your apparent expertise (I have no real expertise myself to really
> evaluate that of yours on this field), I shall offer you a word of wisdom nevertheless:

Hmm, your expertise is not good enough to evaluate my knowledge but it is good enough
to say that Andre understands well error correction algorithms ? Also if you don't trust
my knowledge, why coming to cdfreaks every now and then to ask me questions ? Anyway,
I was not flaming anyone here, CIRC is complicated and its understanding is absolutely
not required to write a DAE tool. Generally speaking I try to help people on every
board I visit and I flame only those who like to talk more than they actually know.

> PS If the only thing we can do when talking with authors (whether that be EAC, OGG,
> MPC or other authors) is to bitch, demand, moan and attack the person, I don't think
> we'll have much to look forward to, in terms of future development of those developments
> in question

Hmm, actually with OGG or MPC I can get the source code and try to improve it as much
as I like, while with EAC all you can do is beg Andre. I generally have good contacts
with tool authors : they explain what they do, I make suggestions and after an adult
discussion things sometimes get better. But how am I supposed to help when the author
refuses to explain what he does ? Moreover, why would I even want to help someone who
prefers to let people use broken code for one year instead of explaining what he does
and be immediately corrected ? That's why if I were a DAE freak I would spend my time
trying to improve an open source ripper instead of relying on the good will of a single
guy.

[JeanLuc]

Best luck to you, but error correction cannot occur outside of the drive.

There should be no problem (for someone who really knows his stuff like some engineer working for a drive manufacturer) in coding a software ReedSolomon decoder - it would be more problematic (if not impossible without severe hardware modifications) to get the (already de-interleaved and error-flagged) "raw" data from the drive before data actually gets corrected and exits the RS decoder stage ... PIO once asked about that at digital-inn (about grabbing the C2 error flags IIRC) and everyone agreed on the nonexisting possibility ...

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.

Now that is some good news ... I hope you will find some good solutions and find the time to finish them .. things can only get better for all of us.

This post has been edited by JeanLuc: Jan 6 2004, 21:49

[spath]

> There should be no problem (for someone who really knows his stuff like some
> engineer working for a drive manufacturer) in coding a software ReedSolomon
> decoder - it would be more problematic (if not impossible without severe
> hardware modifications) to get the (already de-interleaved and error-
> flagged) "raw" data from the drive before data actually gets corrected and exits
> the RS decoder stage ... PIO once asked about that at digital-inn (about
> grabbing the C2 error flags IIRC) and everyone agreed on the nonexisting
> possibility ...

Indeed, that's why error correction by software is illusory and developers of DAE
tools should better focus on other features.

[lnxguit]

JeanLuc and Eli:
yes, it IS possible. For file naming, I use this format:
Artist\Album\Artist_Track#_Song Name

Go to the "EAC Options" page and enter this formula:
%A\%C\%A_%N_%T

[pholzmann]

Back to his question early on... what I would love to see...

#1 by far: better support for storing (in a nice way) the rest of the information that is BEST retrived when ripping.

In particular: shouldn't the CD ID be savable as a tag -- perhaps in the filename, or in the CUE, or in the file itself, or...???

And, how about adding REM for Year and Genre to cues?

Secondary... some ease of use nit-picky things...

How about making default Image filename be the artist-title (as one gets anyway when choosing export-to-clipboard? Saves a click...

How about a way to "locK" the info for a CD on screen? Sometimes a CD is not found in FreeDB... *and* the track info is on the CD itself but not on the sleeve... only solution is hand write or photocopy the CD surface... bleah!

that's enough for now, or at least all I can think of right now
p

This post has been edited by pholzmann: Feb 7 2004, 09:01

[bobnick]

His idea was that it should be able to:

1. emulate the more advanced error correction schemes many good standalones show when being compared with consumer-class players with a post-processor

2. after the DAE host application (in this case - EAC) encountered and thoroughly logged unrecoverable read errors.

This would be some kind of possible future outlook ... -

I have only just found this thread.

Actually it was to implement the more advanced interpolation routines available. Most CD-ROM drives have very primitive interpolation routines especially where there are 2 or more consecutive errored samples. So even if the rip is not 100% accurate, it will at least sound more acceptible.

Pio has already pointed out to me that this log is already implemented in the analyse part of the Andre's DAE testing.

Regards,
Bob

[nof8r]

PS- Does anyone know if it's possible to get EAC to create ~\<artist>\<album>\<nn><name>.mp3 format directories when it rips CDs?

Unfortunatly its not :-(

I also would love this feature

Not true - just use something like this in the filename preferences :

%D\%C\%N_%T

[MJT]

Err...

1. The topic is over a year old.
2. The answer had been given here.

This post has been edited by MJT: May 24 2005, 01:07

[HbG]

The only option i miss in EAC is support for pipes, so you can use any external encoder with any config on the fly, rather than be dependant on DLL's with limited options.

[Synaptic Line No...]

The only option i miss in EAC is support for pipes, so you can use any external encoder with any config on the fly, rather than be dependant on DLL's with limited options.

That makes the assumption that we will always be able to encode faster than we can rip.

I suppose in the future and probably right now for people with recent computers, encoders will generally be faster than an accurate rip, especially with the advanced optimizations GCC4 is supposed to have??

This post has been edited by Synaptic Line Noise: May 24 2005, 12:01

[HbG]

The only option i miss in EAC is support for pipes, so you can use any external encoder with any config on the fly, rather than be dependant on DLL's with limited options.

That makes the assumption that we will always be able to encode faster than we can rip.

I suppose in the future and probably right now for people with recent computers, encoders will generally be faster than an accurate rip, especially with the advanced optimizations GCC4 is supposed to have??

Even if they're not faster, you'd have to either buffer or halt the rip for a while. Is that a very big problem? It's the same as on the fly encoding with a DLL, you just have much more control.

[convil]

Does anybody know that if EAC works on windows x64??
Or do we need a 64-bit version of EAC??

[Halcyon]

All 32-bit apps should work with 64bit Windows.

[borndevil]

z):

why not MAC?

[AtaqueEG]

z):

why not MAC?

Ask Andre

Most likely lack of time

[rjamorim]

Most likely lack of time

Lack of compiler actually, if anything

This post has been edited by rjamorim: May 26 2005, 17:25

[jkauff]

z):

why not MAC?

Ask Andre

Most likely lack of time

Most likely lack of a Mac. He's still a student, after all, and postcard-ware doesn't generate much cash for the hardware budget.

Jim K.

[Shade[ST]]

z):

why not MAC?

Ask Andre

Most likely lack of time

Most likely lack of a Mac. He's still a student, after all, and postcard-ware doesn't generate much cash for the hardware budget.

Jim K.

I think what was meant was Monkey's Audio Codec, not Macintosh Computer...

[rjamorim]

I think what was meant was Monkey's Audio Codec, not Macintosh Computer...

EAC already supports Monkey's Audio

[jkauff]

Lack of compiler actually, if anything

That was my first thought, too, but a quick Google turned up a couple of Modula2 compilers for OS X. They're ISO Modula2, though, and much of Andre's code probably pre-dates that standard. Did Andre study with N. Wirth? They're both in Switzerland.

Jim K.

This post has been edited by jkauff: May 27 2005, 13:47

[rjamorim]

That was my first thought, too, but a quick Google turned up a couple of Modula2 compilers for OS X. They're ISO Modula2, though, and much of Andre's code probably pre-dates that standard. Did Andre study with N. Wirth? They're both in Switzerland.

Andre uses Stony Brook Modula 2, which is not really ISO-compliant. And Stony Brook provides no MacOS X version of their compiler.