Thread: Wishlist for new functions of EAC 1.0

Originally Posted by greynol

Depending on why you want to swap channels, undoing a 2-byte offset might be a better idea.

i do not understand, maybe you can help me with this one.
I installed EAC in a friend's computer once to do some rips, and i only realized the left and right channels where swapped after i made the extractions. All i want is for the WAV Editor to be able to correct this, if there isn't already a way to do this.
I know a bit of Audacity and Pro Tools, but i hope the EAC WAV Editor can make this a bit easier.

Your suggestions will be very welcomed
Thanks

I have never seen a drive that simply just swaps channels. All the ones that I've see which appear to swap channels actually offset the data by two bytes. Not only does this swap channels, but it also time-shifts one of the swapped channels relative to the other by one sample. This is nowhere near as easily fixed in a wave editor as simply reversing channels. It is easily fixed using a hex editor, however. I'm sorry, but I don't recall whether you need to remove two bytes at the beginning of the PCM stream and add two bytes (0x0000) to the end (or steal from the next track), or if you need to add two bytes to the beginning (or steal from the previous track) and discard the last two bytes at the end.

It would be helpful if Exact Audio Copy could input a batch of audio files and output their CRC's. This is useful to check the integrity of audio files that have already been ripped by comparing the CRC's of audio files with their corresponding CRC's in the EAC log files.

Currently, with version 1.0b1, the only way to get CRC's from audio files is to use the "Process WAV..." menu item, which is both cumbersome (because it does too many other things, including WAV editing) and inefficient (because it only deals with one file at a time). Ideally it would be possible to drag and drop and entire directory of audio files, have EAC examine the files and output CRCs.

I'd like to have a more simple version of EAC or something very close to it. Too many boxes to check or uncheck. Too confusing. German technology is some of the best in the world like my Siemens solar panels, but I can't get the hang of EAC. I just need a ripping / burning program that doesn't give me disks with dropouts. I want the disks to play in my Onkyo (2007 - not too old) player in the living room, not on my computer. Not interested in compressed files either.
If there is no easier version of EAC, I would greatly appreciate someone suggesting the next best thing and I'll get out of your hair. Thank you
P.S. It has to run in Windows98se. This OS is quite adequate for a separate computer that never goes on line.

Originally Posted by greynol

I have never seen a drive that simply just swaps channels. All the ones that I've see which appear to swap channels actually offset the data by two bytes. Not only does this swap channels, but it also time-shifts one of the swapped channels relative to the other by one sample. This is nowhere near as easily fixed in a wave editor as simply reversing channels. It is easily fixed using a hex editor, however. I'm sorry, but I don't recall whether you need to remove two bytes at the beginning of the PCM stream and add two bytes (0x0000) to the end (or steal from the next track), or if you need to add two bytes to the beginning (or steal from the previous track) and discard the last two bytes at the end.

Hello there,

My friend told me that the Swap Channels option was selected in his EAC. Does this change anything? Would i still need to fix my files in a Hex Editor or would an Audio Editor be enough to do the job? Can the EAC editor fix this?

Thanks

EAC still tries to save some files in its program folder, where the user executing it has no write permissions. Thus those files get written to the VirtualStore folder.

It would be nice if EAC would finally become fully compatible with Windows versions newer than XP.

The ability to create cue-sheets for individual indices. The only way I've found to create those is by splitting an image via EAC, but creating an image just to split it for getting a specific type of cue seems a bit unnecessary.
EDIT: Also, would it be possible to only rip a specific index of a track instead of the whole track with its indivicual indices? I'd find that helpful, since you need to rip index-based in order to get the a track 01-pregap with a length less than 50 blocks, but ripping the whole track seems unnecessary (and it also looks a bit redundant in the merged log for the whole rip).
EDIT2: And when I'm already at it, I'd find checksums for index-based rips and test & copy function for range/catalog/index-based rips useful as well (I always rip those twice and compare the CRCs manually - for individual indices, I even calculate the checksums manually).

Also, and this doesn't perfectly fit in here, but the "Create log files always in english language" option doesn't completely work, some parts are still in the program language (Used output format and the AccurateRip report at the end) , which results in a mixed language log.

Two requests:

1) The ability to do a "Various Artists" where you actually define an Album Artist. (I don't want "Various" or "Various Artists" listed anywhere) For example, DJ mixes.

2) The ability to name and tag based on CD number (I think this one is already in the list). For example 1-01 Artist - Track.mp3, 2-15 Artist - Track.mp3 etc

Thanks!

agressiv

Originally Posted by greynol

I don't believe I saw it mentioned in this discussion, but the ability to skip the test extraction for tracks that get AR verification when using T&C.

How would that work? Doesn't the test extraction come before the copy? Or would it simply verify the test extraction against AR, write it to disk and skip the 'copy' extraction?

There is no reason why the order can't be reversed, or is there?

It would be great if there were an option to have EAC append a version number to a track if another track with the same filename exists (i.e., create "songtitle (2).mp3" if there already is a "songtitle.mp3" from the same CD). This would eliminate the possibility of accidental overwrites, if you don't happen to notice the duplicate titles.

Yes, I know you can include the track number in the filename to avoid this problem, but honestly I don't want to change the filenaming convention for thousands of existing tracks just for the very occasional case of multiple tracks with the same title on the same disc. Besides, I prefer not to have information for which I have no use in the filename.

Originally Posted by Andre Wiethoff

For better reading, here is a new wishlist...

Hi there. I've installed 1.0 beta 2, I like the progress you made, congratulation. I'm also enjoying the fact that you have a nice wishlist.

Allow me to comment on your wishlist and add my own wishlist. I hope you won't get offended ;-)

Originally Posted by Andre Wiethoff

- Remove option to ignore silent samples for CRC calculation
- Remove "ignore null samples in CRC calculations"

I'm one of this misguided user that started with that second option enabled, because it was the default in EAC. I found it very hard to get away from it, because of consistency. I want to re-scan old CDs and see if the new CRC match those old logs.

I understand that this option should go, but I will be left unable to match those old CRCs. I wonder if it's possible to convert from one CRC to another in some way (I have the FLAC files around).

Originally Posted by Andre Wiethoff

- Skip test extraction if real extraction has AR match

I've got a better idea, see this thread :
http://www.digital-inn.de/exact-audi...tml#post133042

The idea is that you should do the first pass in burst mode, check the AccurateRip result, and for those failing the AR, rip them again in secure mode. That's the best of both words.

Originally Posted by Andre Wiethoff

- better CRC algo for comparisons (SHA?)

Same deal as above. When I test a new version of EAC, I check that it generates the same CRC as an older version. It's a bit like AR v1 vs. AR v2, I personally dislike AR v2 because the database has much less coverage and all my logs have AR v1 CRCs.

Originally Posted by Andre Wiethoff

- merging several (e.g. burst, from several drives) extractions to one, choosing the audible best one

Not trivial to implement, but would be nice. I personally do that by comparing WAVs and picking the blocks that are common across many rips. If I'm in a hurry, I pick the track that has less differences to other tracks. C2 may help as well.


My own wishlist were already in the old thread :
http://www.digital-inn.de/exact-audi...tml#post133040
o Change various default to safer values.
o Default to always generate a log file.
o Always add the AccurateRip v1 CRC and AccurateRip v2 CRC in the log, even if no AR match.
o Add an option/toggle to use AR v2 CRC instead of EAC CRC in the Read-CRC, Test-CRC and CRC-match colums, to compare two drives with different offset.
o Test mode : add an option to automaticaly generate a log file.
o Metadata editing in parallel with ripping.

New items for my wishlist :
o Compare WAV : Accept FLAC files as input. I find it tedious to have to externally decompress the FLAC files to be able to compare them.
o Save Pre-Emphasis status in the log file
o Option to save art as Folder.jpg, not embedded in file.
o When "Various Artists" is selected, set the "ALBUM ARTIST" tag with the "CD artist" field :
http://wiki.hydrogenaudio.org/index...._Tag_Standards

Originally Posted by Andre Wiethoff

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

Actually, one reason I prefer EAC over dBa is that I get more choices of ripping modes, whereas Spoon is stubborn in supporting only a single one.

EAC support : Secure, Secure + C2, Burst
dBa support : Burst + C2

This diversity is crucial, as different drive and CDs react differently to different method. I found that my PX230 is very good in burst mode, but poor in secure mode, this is probably why Spoon recommend this drive ;-) On the other hand, my SH162L and iHAS324-A are very good in secure mode, and just ok in burst mode. But, it's also dependant on the CD. I have some CDs that have pressing bugs triggering problems in secure mode or burst mode, in particular I have one CD that was very bad with dBa.

I agree that Burst+C2 is the best method if you implement only one. So, I would welcome you adding a Burst + C2 method, but please please don't get rid of the other methods. Especially that those methods are well tested by now. And also, please implement my suggestion of having T&C using two different methods (see above) to increase diversity and enable user to benefit from this diversity.

Another thing that really would need changing is the cache defeat strategy. Nowadays, PCs have plenty of memory. Instead of reading small block, trashing the cache, and re-reading the same small block, I would stream the entire CD in memory, re-read a second time and while doing the second read figure out the differences with the first read and perform re-reading as needed. That would make performance with caching drive much better, as you don't need to trash the cache between the first two reads, and would not change anything for non-caching drives.

Good luck...

Jean

Originally Posted by dashford

It would be great if there were an option to have EAC append a version number to a track if another track with the same filename exists (i.e., create "songtitle (2).mp3" if there already is a "songtitle.mp3" from the same CD). This would eliminate the possibility of accidental overwrites, if you don't happen to notice the duplicate titles.

There is another reason to implement that. When I have a track with errors, I rip it multiple times with different drivers and in different modes and I compare the tracks with Compare WAV. Currently, I need to rename the previous track prior to ripping again, and this feature would help.

Note that I personally don't see that as essential as it's easy to work around by being careful ;-)

Jean

Originally Posted by Charleston

It would be helpful if Exact Audio Copy could input a batch of audio files and output their CRC's. This is useful to check the integrity of audio files that have already been ripped by comparing the CRC's of audio files with their corresponding CRC's in the EAC log files.

Actually, let's make it one better and allow to save those CRCs in a log file. And also output AR v1 and AR v2 CRCs (yes, they are not true CRC, I know).

My use is slightly different. I have a huge collection whose CRC was computed using the wrong option (remove NULL samples), so I need to regenerate those CRCs more or less in batch mode and save that in log files.

Note that FLAC has embedded integrity check using md5, and you can use many tools such foobar's File Integrity Verifier to check those. The md5 is the signature of the uncompressed data, so the only possibility to get a corrupted FLAC file that this md5 would not flag is if the WAV was corrupted between EAC and the FLAC encoder, which is highly unlikely.

Originally Posted by Andre Wiethoff

- better CRC algo for comparisons (SHA?)

Note that it would be interesting for EAC to compute the same md5 that FLAC generates and use this md5 in the EAC log. I think it would open quite a few interesting possibilities of cross checking things between EAC logs and FLAC files.

Have fun...

Jean