Skip to main content

Topic: Progress of the next Exact Audio Copy (Read 19238 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • JeanLuc
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #25
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 ... -
The name was Plex The Ripper, not Jack The Ripper

  • JeanLuc
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #26
Quote
Quote
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 ...
The name was Plex The Ripper, not Jack The Ripper

Progress of the next Exact Audio Copy
Reply #27
Quote
Quote

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
  • [*][*][*]
Progress of the next Exact Audio Copy
Reply #28
Quote
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
  • Last Edit: 06 January, 2004, 09:46:03 AM by deej_1977
No inspiration

  • spath
  • [*][*][*]
Progress of the next Exact Audio Copy
Reply #29
@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
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #30
Quote
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 ...

Quote
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.
  • Last Edit: 06 January, 2004, 03:49:41 PM by JeanLuc
The name was Plex The Ripper, not Jack The Ripper

  • spath
  • [*][*][*]
Progress of the next Exact Audio Copy
Reply #31
> 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
  • [*]
Progress of the next Exact Audio Copy
Reply #32
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
  • [*][*]
Progress of the next Exact Audio Copy
Reply #33
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
  • Last Edit: 07 February, 2004, 03:01:21 AM by pholzmann

  • bobnick
  • [*]
Progress of the next Exact Audio Copy
Reply #34
Quote
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
  • [*]
Progress of the next Exact Audio Copy
Reply #35
Quote
Quote
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
[a href="index.php?act=findpost&pid=170183"][{POST_SNAPBACK}][/a]


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

%D\%C\%N_%T

  • MJT
  • [*][*][*]
Progress of the next Exact Audio Copy
Reply #36
Err...

1. The topic is over a year old.
2. The answer had been given here.
  • Last Edit: 23 May, 2005, 08:07:54 PM by MJT

  • HbG
  • [*][*][*][*]
Progress of the next Exact Audio Copy
Reply #37
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.
Veni Vidi Vorbis.

Progress of the next Exact Audio Copy
Reply #38
Quote
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.
[a href="index.php?act=findpost&pid=300106"][{POST_SNAPBACK}][/a]


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??
  • Last Edit: 24 May, 2005, 07:01:55 AM by Synaptic Line Noise

  • HbG
  • [*][*][*][*]
Progress of the next Exact Audio Copy
Reply #39
Quote
Quote
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.
[a href="index.php?act=findpost&pid=300106"][{POST_SNAPBACK}][/a]


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??
[a href="index.php?act=findpost&pid=300115"][{POST_SNAPBACK}][/a]


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.
Veni Vidi Vorbis.

  • convil
  • [*]
Progress of the next Exact Audio Copy
Reply #40
Does anybody know that if EAC works on windows x64??
Or do we need a 64-bit version of EAC??

  • Halcyon
  • [*][*][*]
Progress of the next Exact Audio Copy
Reply #41
All 32-bit apps should work with 64bit Windows.

  • borndevil
  • [*]
Progress of the next Exact Audio Copy
Reply #42
z):

why not MAC?

  • AtaqueEG
  • [*][*][*][*][*]
  • Members (Donating)
Progress of the next Exact Audio Copy
Reply #43
Quote
z):

why not MAC?
[a href="index.php?act=findpost&pid=300666"][{POST_SNAPBACK}][/a]


Ask Andre

Most likely lack of time
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

  • rjamorim
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #44
Quote
Most likely lack of time
[a href="index.php?act=findpost&pid=300696"][{POST_SNAPBACK}][/a]


Lack of compiler actually, if anything
  • Last Edit: 26 May, 2005, 12:25:18 PM by rjamorim
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • jkauff
  • [*][*][*]
  • Members (Donating)
Progress of the next Exact Audio Copy
Reply #45
Quote
Quote
z):

why not MAC?
[a href="index.php?act=findpost&pid=300666"][{POST_SNAPBACK}][/a]


Ask Andre

Most likely lack of time
[a href="index.php?act=findpost&pid=300696"][{POST_SNAPBACK}][/a]


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]
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #46
Quote
Quote
Quote
z):

why not MAC?
[a href="index.php?act=findpost&pid=300666"][{POST_SNAPBACK}][/a]


Ask Andre

Most likely lack of time
[a href="index.php?act=findpost&pid=300696"][{POST_SNAPBACK}][/a]


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.
[a href="index.php?act=findpost&pid=300715"][{POST_SNAPBACK}][/a]

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

  • rjamorim
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #47
Quote
I think what was meant was Monkey's Audio Codec, not Macintosh Computer...
[a href="index.php?act=findpost&pid=300716"][{POST_SNAPBACK}][/a]


EAC already supports Monkey's Audio
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • jkauff
  • [*][*][*]
  • Members (Donating)
Progress of the next Exact Audio Copy
Reply #48
Quote
Lack of compiler actually, if anything
[a href="index.php?act=findpost&pid=300714"][{POST_SNAPBACK}][/a]


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.
  • Last Edit: 27 May, 2005, 08:47:31 AM by jkauff

  • rjamorim
  • [*][*][*][*][*]
Progress of the next Exact Audio Copy
Reply #49
Quote
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.[a href="index.php?act=findpost&pid=300920"][{POST_SNAPBACK}][/a]


Andre uses Stony Brook Modula 2, which is not really ISO-compliant. And Stony Brook provides no MacOS X version of their compiler.
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org