DT5

Does there exist somewhere a wishlist for new functions in EAC?
A list where users can add new entries?

Andre Wiethoff

No, but I think I will make this one sticky, so anybody can enter a wish...
Besides, there will be a new version soon (don't ask when, at least not in the next 3-4 weeks) and so I think these wishes will not make it in this version... (as it is nearly feature complete and just need some more bugfixing etc.)

Wishlist so far (sorted by priority):

- plug-in support for retrieving track information from different sources (e.g. AMG, etc.)
- album art display, storage, and writing to ID3/folder (planned anyway )
- automatic detection of song/artist name based on filename (e.g. with regular expressions)
- this detection can also be used for tagging on "compress WAVs"
- add a placeholder for filename creation for track length (min:sec)
- user defined character replacement tables
- user defined sound that plays back after ripping/compressing (instead of ping)
- making EAC more Vista "compliant" by e.g. using the user directories (or "all users") for all data that need to be written during the work with EAC
- Writing the average read speed for each track (or image) in the log file
- Option for only writing ID3V2 tags
- Unicode support for freedb, etc.
- Status of "No use of null samples for CRC calculations" in the log
- better CRC algo for comparisons (SHA?)
- Option for not writing ID3V1 tags, when writing V2 tags...
- Support for WMA CBR modes
- Seperate selection of the Log file language (e.g. for creating english log files)
- FLAC & WavPack decompression (also for on-the-fly burning of CDs)
- possibility of using a relative path for decompressor in the options
- track number offset (e.g. for audiobook ripping)
- User defined character replacement maps
- Test for overreading capabilities on the start of extraction
- Test for compression options (and display of a sample command line)
- Menu for removing trailing spaces from "cd title", "artist" & "track titles"
- Menu for removing more than 1 consecutive spaces from all info
- Showing the used command line for the given command line compressor (and test whether it works ok)
...
- merging several (e.g. burst, from several drives) extractions to one, choosing the audible best one
- comment field in the main screen which can be edited for ID3 comment field
- signature of log files
- retrieving original CD-Text and adding it to CUE Sheet (and use it for writing)
- setting compression priority not dependingly to EACs (perhaps not setting EACs anymore at all?)
- plug-in support for EAC automation (I still don't know what to automate and how? Macros? Script Language?)
- a graphical display that shows us, visually, approximately where on the CD a scratch is
- deleting of WAV files which are skipped due to high error recovery
...
- "test gaps on silence" should test offset corrected
- Native multi-encoder support (like Mareo)

Beyond any priority:
- Better extraction mode, C2 based (basically a complete rewrite of the extraction engine)


cu, Andre

greynol

I'd like to see improved C2 performance similar to that of the new dBpowerAMP. I have no idea how difficult this would be to implement but it would be a huge improvement. Basically it would be good to utilize C2 pointers during re-reads and perhaps figure out a way for EAC not to pass bad data off as good data when using drives like the popular NEC ND-3500AG as well as others that use the same very common chipset.

calestyo

Would you give a little feature preview?

Chris.

DT5

I think that the biggest wish for the most users would be test&copy for images. I hope that this feature will be integrated already in the next version.

I personally have still some wishes:

1) Since I had problems after my registry values were not correct ( UseCombinedSampleOffset was FF instead of 00) could EAC check while it is starting whether these values make sense? Greynol wrote that this value can be wrong after changing from beginner to advanced mode.
2) Is it possible to integrate the accuraterip results into the log-file? If I use accuraterip to verify that the rip was succesful then it has to be in my opinion integrated to the log.
3) It would be nice if you would create the possibility to use plug-ins. I have in mind that you could give the control to an external dll which can automate routines which are not yet integrated.
4) Native support for cue-sheets with flac-files, eg while ripping creating the right cue-sheet (with the flac and not the wav extension) or both (flac + wav). And the internal CD-writer should support flac files as it does already for ape. So there is no need of decoding manually.
5) The information in the log-file about the used output format should be changed. The most are using flac. So the Bitrate information is wrong. Perhaps you could use instead 'lossless'. Is there a need to use the path? I would find it more important to integrate the version number eg flac 1.1.3 or flac 1.1.4.


DT

Andre Wiethoff

1) FF is a "good" value (true), while 00 is also a good value (false)...
2) It is in, also with much better AccurateRip support (is possible only because of a new version of the AccurateRip DLL - otherwise, I couldn't get the results)
3) What kind of plugins, when should they be called, what should they do, what should they get as parameters? It is already possible to call external .exe after extraction of a track and after all extractions (and I think also after all compressions)...
4) Yes, flac decompression (after the results I saw in the poll) should be in the next next version. I tried it once, but the SDK was so complex, I didn't find in easily... I will have a look again (but not for this next version coming soon though)...
5) If flac is used, isn't there a naming that it is a flac? Then everybody should be knowing that it is lossless (and those who do not know - will not care). The bitrate is ok, even an uncompressed WAV file has an bitrate. I think it is good to know how good a file could be compressed (e.g. uncompressed CD audio has a bitrate of 1378 kBit/s)
It is difficult to include the version number of a command line encoder, as this would mean parsing the command line somehow. I did this for some LAME versions (and still do), but I had to change this for some times because several compiles print the version information at a different position and using different texts...

cu, Andre

Andre Wiethoff

The preview :
Much much better accurateRip support (whatever that means )
Test&Copy for CD images
Better Configuration Wizard (for LAME & Flac, as also for filenaming options)
Another feature that I don't know yet if it really will make it into the release (so I am telling nothing about it )
Fixed many bugs and problems (CD-Text support for CDRDAO and other problems removed with CDRDAO)
Unified installer (with CDRDAO, AccurateRip and Flac)...

Hope that you will like it

cu, Andre

Andre Wiethoff

I am not sure about this, I think I leave this alone...
First of all : There is no proof for any improved C2 performance. I had such a mode, which used C2 for error correction, but it failed miserably. Of course, I accept the fact that there are nowadays many drives that really delivers reliable C2 information. But this is no reason for 90% of the drives which can't. This tool set of using C2 pointers is dangerous for unaware users (C2 correctness can not be autodetected).
Spoon itself tested this with one CD only (I don't know whether there are independed test with more CDs), the results were:
dbpoweramp : 64 error free, 16 errors
EAC : 53 error free, 27 errors.
My bet is more the automatic "support" of AccurateRip, whenever the checksum is different, it knows that the track has an error an it can reread the track in order to get a good result... He even tested it with a CD with a known confidence of 19...
In EAC, there is no automatic testing for this (and will not get one), but it is easy to do this manually (even more with the better AccurateRip support).
I doubt that there is a dramatic improvement (other than accurateRip), and so I do what I think the best is for all users, and not for tests with a specific test environment.
Anyway, a further thing that would also help on dbPowerAmp (and which is also not automatic in EAC) is complete reripping of a track, and not only of error positions...
Further, it will only have impact on the few CDs that really have errors, and then EAC most probably will tell that there were errors (the table above only showed how many tracks could be read error free...)
I don't think so, that I will go from manual to automatic though... If you want to spend $28 for dbPowerAmp (plus version updates when they occur), it is your right. I am not a believer, but if it works for you - great!

cu, Andre

PS: I would propose to do a real test for a CD which has no accurateRip entry...

DT5

You are right, when I right-click for instance on flac.exe then it doesn't show the version information. I thought that all these encoders had their version information included as every normal program.

calestyo

That "thanks" was a pre-thanks for the new relase... unfortunately I can't give you mor than one thanks per post,... if not you would have also received some pre-thanks for you upcoming C++ port

Anyway:
*Curious*

A feature we're all waiting for.... Until know I've always ripped first as image and then again with test&copy and diffed the results (of course one had to keep in mind that test&copy has no track 1 pregaps)


Is it extracton-quality/secure-error-finding related? (See question below)

Will there be a complete list? I ask because I'm just ripping my complete CD collection and if there were any extraction-qualtiy/security related bugs I would stop and wait.

Of course not ;-) :-P

Andre Wiethoff

The new feature is something of tag info filling... More I will not say...
The bug-fixes indeed fix some small issues on extracting, but mainly if an extraction (range/track/index) is smaller than 1/3 seconds...
Anyway, I also can not guarantee that the new version is error free, so I don't know which version would be better for extraction...

cu, Andre

calestyo

I remember that I experienced problems with very small gaps (e.g. 33 frames or so)... but this error should have been completely avoided when ripping a complete image, right?

calestyo

btw here an actual feature request:
1) As the different gap detection methods might give different results: Add a new "method" that simply makes CUE sheets for each gap detection methods.
(The information which gap detection method was used should also be written to the log).
2) Add a button or so, that clears the current gap data (currently one has to eject the CD for doing this).

Unregist84

Adding CD TOC to tags.

Adding AccurateRip data to tags

A major interface overhaul/update

Add option to automatically create a cue file with each full disc/all track (not image) rip

Add ability to calculate album gain

greynol

Regarding improving the way EAC uses C2 pointers:

It was never my intention to start any kind of argument over the matter, though I think you're really underestimating the advancements Spoon has made with his ripper. Before passing judgement you should at least try the program. I was every bit as skeptical as you are before auditioning the program and it wasn't until his seventh alpha release that I could see it consistently and accurately rip things that EAC could not.

If you like I can fill your proposal and provide you with test data demonstrating dBpowerAMP's advantage over EAC without AccurateRip enabled during ripping.