utfwb

would it be possible to add support for utf-8 when exporting to freedb

Catweasel

An option to play a WAV-file instead of the system-ping after extracting would be great

Irios

There needs to be added a CRC of the .log file itself so people cannot edit the log files manually.
I see a lot of people "cheating" and editing away errors and stuff like that, and it would be nice with a feature to validate/verify the contents of a log file.

jean2

I personally believe that this is going to make it only marginally harder for people to cheat. Even if you use a Private/Public crypto signature of the log, the fact that EAC has to generate the signature on the user PC means that this user can replicate the signature process on any chosen log.

I feel this is a human trust issue. Technology can not workaround humans. Note that you would also need to trust that the user use a capable ripper and that it's set properly. I personally don't have this issue because I only rip my CDs.

Regards,

Jean

jean2

Hi,

This is something I wrote in another thread, but it probably belong here. Sorry for the dup.

1) Set the EAC default to generate a log
-----------------------------------------

It's easier to delete a log than the recreate it. Therefore the default of EAC after installation should be to automatically generate a log.

2) AccurateRip CRC always in the log
-------------------------------------

Basically, add AccurateRip CRC to the log even if the CD is not in the AccurateRip database.

First application : allow to compare logs across different AccurateRip enabled rippers (like EAC vs. dBPowerAmp).

Second application : when ripping and testing on two different drives, very often the EAC CRC of the last track does not match due to drive offset differences. On the other hand, the AccurateRip CRC would match, saving the need to analyse the tracks in details.

3) Test mode - allow to ignore last samples
--------------------------------------------

Similar to previous : when ripping and testing on two different drives, very often the EAC CRC of the last track does not match due to drive offset differences. It would be nice to have an option so that the Test&Copy mode would be able to ignore the last samples of the track and indicate when a track match.

I understand that the test&copy match is probably done by comparing the EAC CRC, so this is probably hard to implement.

So, maybe the option should be : use AccurateRip CRC to check track match in Test&Copy instead of the EAC CRC. Of course, that should only be an option.

4) Test - generate a log
------------------------

Add an option so that when doing a Test, it automatically generates a log. Bonus points if the log has a different name from the log of Copy/Rip (we don't want the two logs to overwrite each other).

5) FreeDB editing in parallel with ripping
----------------------------------------

I found that during ripping, I spend a lot of time fixing the FreeDB information. There is always some errors, or I often want to do things differently, and I spend time renaming the tracks. During that time the CD is totally idle in my drive.

I don't want to edit the FreeDB information after ripping for various reasons. First, it becomes more messy as I need to fix both the tag and the filename/dirname (and if I was anal the content of the log). Second, if for whatever reason I need to re-rip the disk, I need to refix those. So, getting it right in EAC is important.

So, what could be nice is for EAC to start ripping the WAV immediately. While the drive is ripping, I edit the FreeDB, album name, track name as much as I want. Then, when I finish the edit, EAC start compressing the tracks with the proper name and tags. When EAC finish the ripping, I put a second disk, and the compression of the first CD happens in the background while I'm ripping and editing the second disk.

This might be harder to implement, but I guess it cost nothing to ask ;-)

Thanks for EAC, and have fun...

Jean

jean2

Hi,

In the light of the various consistent errors that I've been finding, I've been thinking of what would be the best workflow for the average user of EAC.

The detail of those consistent errors :
EAC Forum - Peculiar AccurateRip result
EAC Forum - Peculiar ripping result

I personally use two drives with different chipset, but that is clearly a non starter for average users (how many laptops can support two drives). My procedure also involve too many individual steps.

What we want is to maximise diversity. AccurateRip gives us the best diversity. Different drive give use very good diversity, but is not practical. Different reading mode give better diversity that I would have guessed.

We also want to maximise speed and minimised wear and tear on the drive. The vast majority of CDs will read fine and be in the AccurateRip database, in other words, burst mode is prefered.

And we want to go easy on the user with a "one click does all", which is why I think we need to introduce a new action. Maybe it could be a mode, I guess Andre will have to figure out what work best.

CB&AR&TR - Copy Burst & AccurateRip & Test Replace action
------------------------------------------------------------

The first part of CB&AR&TR is a copy pass done unconditionally in burst mode regardless of the actual mode setting for the drive. The resulting FLAC tracks are saved on the HDD.

The second part of CB&AR&TR is to compare the AccurateRip CRC of the tracks with those in the AR database. If the AccurateRip confidence match of all the tracks is greater than a user-defined threshold, the action stop here. The default threshold should probably be 1, personally I would use something like 5. If any of the track is not found in AccurateRip, does not match, or its confidence is below the threshold, we go to the third part.

The third part of CB&AR&TR is a test pass in the actual mode setting of the drive (burst, fast, paranoid, secure - with/without C2 and cache). Ideally, we would only rip the track that failed, but could just rerip everything because of between track sync. Then, if the CRC of the test track if different from the CRC of the first pass (Copy Burst), the new track replace the old one. I think it would be nice to optionally save the track from the first pass.

If the drive mode is burst, it does two burst passes and this is equivalent to the Test & Copy action which is popular with so many people. The only difference is that the second burst pass is ommited if AccurateRip matches.

If the drive mode is secure with the proper setting, you have one burst pass and optionally a secure pass, something very similar to my workflow and which I believe would give you the best possible security with EAC. And I even believe that this would be better than dBamp, it would be as fast for most disks and more secure for the rest.

If you have more questions, feel free to ask...

Jean

Irios

I dont agree. If the developer would add some sort of checksum based on the contents of the log file - in the log file itself - you'd have to know the algorithm of the checksum to reproduce it, right?

Unless someone makes a log-file-generator exe (in the same way as warez keygens) there is no way a user of EAC would know how to calculate the checksum. No-one is gonna sit down and reverse-engineer the algorithm just to create fake .log files. (At least I hope not)

In turn if there was a validation feature in EAC (i.e. drag and drop a .log file into the EAC main window to validate) you could easily check to see if someone has been fiddling around with the contents of the log file.

Boiled Beans

I'm not sure if this has been mentioned before, but I would like to have a Test pass for images. For example, after I copy the image in Burst mode, no tracks are verified as accurate rip says the CD might be of a different pressing. So I need to Test + Copy the entire image again to see if the CRC matches.

It would be good if just a Test pass was necessary to see if the two image CRC matches.

Teller

If you rip a second time wouldn't the first become a test copy?

greynol

He's following the advice I give with caching drives that don't provide C2 pointers. Instead of test and copy, I recommend burst copy, check AR results and perform a test pass if needed. My method is geared towards ripping separate tracks, not single-file images.

It would help if there was an F8 equivalent for ranges and images, but that still doesn't address the horrible inefficiency of having to re-rip an entire image in an attempt to fix a small portion that has errors. What's worse is that in burst mode you not likely to even know where they are.

I normally recommend that people suck it up and use secure mode as the copy pass when they insist on ripping to single-file images.

Teller

There is an equivalent, F5 and it has the added benefit of producing a ripping record.

greynol

You can create a log from a test rip (F8) as well.

Anyhow, you can just hit F7 and overwrite the old file. If the checksum is the same as the last then no harm no foul, except for the extra encoding time, unless you're just ripping to wave.

There actually was an F8 equivalent for ranges for a very short time. It was in a bug prior to the official release of V0.99pb2.

Boiled Beans

Thanks for your replies. I use a new method now when ripping images in Burst.

First, I find the shortest track in the album, then I do a Test Pass for that individual track.

If that individual track can be verified as accurate, then I rip the whole album in Burst Mode (Copy only) and check all AR matches.

If that individual track can't be verified as accurate, it's highly likely I have a different pressing**, so I do a T&C in Burst Mode.

This solves my problem of doing a Copy only and finding out my album is not in the database and thus having to do T&C to have a second assurance (means ripping 3 times!)


**From ripping about 30 CDs in Burst so far, even my most scratched CD (put in a paper cover, not in jewel box, so it scrapes against the paper everytime I take it out), managed to get an AR accurate in Burst Mode! Moreover, I select the shortest song (normally 2mins) so it has less likelihood of errors. So it's highly likely a different pressing that it gets no AR accurate, instead of a bad rip.

PlasmaShock

Adding cd number info if there more than one disks in an album for people who like to store music by cd number

RamonSalazar

My wishlist. All of them are for the LOG files:
1. Report MM:SS:FF or MM:SS:NNN time format (i can only guess the real pregap lengths) was checked
2. Report how many null-samples are at the beginning and at the end of the result media file. Of course IF "delete leading..." is checked then report the amount of deleted null samples. Why? LINK.

Important is the null samples at the beginning of the first and at the end of the last track. If there are enough null samples [significantly more than RED+BLUE(without WHITE)], then you can be sure that the rip is exact. Im tired to test it every time with shntool... ((( a decision system would be cool )))
3. Report pre-emphasis
4. Report external aspi dll version

As i know it's impossible to include the criptographic hash key into the data which it is based upon. You can only include the crc key into somewhere to the log file, but it must measure the other parts of it. Unfortunately it would only make cheating a little harder.