Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "A few" EAC improvement suggestions (Read 3964 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"A few" EAC improvement suggestions

(EAC's forum has a link to this thread already)

TOC:
Story 1) Appendable logs without the risk of log-fakers
Story 2) Hashes (Checksums) to verify file integrity
Story 3) Separate AccurateRip values for EAC and dMC users
Story 4) Standards & Profiles
Story 5) Patches
Story 6) And a few more things about AccurateRip to go

EAC is about to take one big step in its development by implementing AccurateRip. Here are some suggestions for making the new version as useful as possible:
==================================================

Story 1) Appendable logs without the risk of log-fakers:
[/u]

Let's presume you're the first person to make an AccurateRip of a certain CD with EAC. You've got two CD drives and one of them knows the secret of overread, and thus is capable of retrieving every sample even from the first/last track.

The other one instead, has a negative offset, so it needs a positive correction value. A positive correction value can only be used in the last track if the drive supports overreading into Lead-out.

And what do you know, this one here doesn't! EAC's "Fill missing offset samples with silence"-option usually does the trick as a lot of CDs end with digital silence but to ensure the 100% accuracy in the rip, the last track must be ripped with a drive capable of overreading to lead-out.

Ripping the first 9 tracks with the offset-impaired drive and then ripping the last and 10th track with the last drive would of course result in two separate logs. Now that doesn't look too nice, does it? So why not rip everything with one drive only? Well,
for starters, it can be very slow and if you've got a motherload of CDs borrowed from the library with the "deadline" closing in, you'll probably want to rip with two drives at the same time.

This is why there should be an option to rip with two drives into the same log.

The append function could also be used when you've ripped a CD that has one faulty track. Now that's something the Überstandard people/other audiophiles don't like if you are doing P2P-sharing  in their hubs.

Having to find another rip source could be painful. Then you decide to go to a DC hub sharing 100% accurate rips. One of the people happens to have the exactly same CD in their share, and in lossless format so it's totally bit-correct. Downloading a losslessly compressed CD can take time though, even with fast connections.

It would be so cool if you could just download that one track your drive couldn't rip and then use the AccurateRip DB's info to verify the downloaded file is 100% accurate. And of course, add the fixed file into the album's EAC log.

The append function would however be way too vulnerable to abuse as the logs we have now are easy to fake. (I think it's less likely for someone to create a fake log entirely from scratch though) That's why I think the should be a change in the log system. In my opinion, a complexly encrypted log file would be a perfect way to prevent people from making logs by themselves. But to make the new logs work nicely, the log editing features would have to be extremely versatile, as stated several lines above. Being able to add a username into the log's filename automatically (as recommanded in the Überstandard) would be great.



Story 2) Hashes (Checksums) to verify file integrity:
[/u]
This one will be a bit shorter:

As far as I know, CRC32 isn't really the most secure checksum algorithm there is. So it would be great to be able to make a choice between, let's say CRC32, MD5 and SHA-1. At least MD5 is extremely fast on my XP1800+. SHA-512 support would be cool too, even though it's a little slower than the others.



Story 3) Separate AccurateRip values for EAC and dMC users:
I think EAC-submitted values should be viewed separately as dMC doesn't feature
secure mode yet. And adding more information fields to AccurateRip would be a good idea. I'm talking about information such as C2 enabled/disabled in the rip or possible offset problems (fill up used?)



Story 4) Standards & Profiles:[/u]
I bet almost every HA member has taken a look at the Überstandard developed by Chris Myden. Making a profile that would automatically ensure the Überness of the rip would be REALLY useful and time-saving. Something like AQScript maybe.

But I myself consider the Überstandard way too strict and then again, too loose in some issues:

- It doesn't require offset perfection from the users' rips
- Share layout requirements way too strict: lyrics in HTML format in the album directory not alloed, and the current naming schemes don't leave enough options. - - Capitalization MUST be correct seems a little too rough, SHOULD would suit better as far as I'm concerned
- It only accepts APS-encoded MP3s, Q8 OGGs and FLAC with the highest compression rate.

Of course, there are lots of good sides in the Überstandard as well, but I think a new standard is desparately needed (or at least major changes in the Überstandard). So here are a few things that could be included in the standard of my dreams:

- Each compression format would have its own substandard. (MusePack, Vorbis, MP3 etc.) The DC hub owner could then decide whether they want to allow 1337 ripped MPCs/AACs/MP3s/APEs etc.
- AccurateRip values would be enough proof of file's 100% exactness, a C2less log would also do.
- Strong recommendation to use Test & Copy with extremely scratched CD's. Believe me, even without C2 used in ripping, I still get different Test & Copy CRCs with < 99.7% quality tracks very often.
- Checksum requirement: MD5 or better (Advanced CheckSum Verifier is very good for making MD5 hashes)



Story 5) Patches:[/u]
A good way to correct those "Suspicious positions" would be, guess what? Patching! If one user has an exact copy of a track they could easily make a patch for the track that has glitches, as long as the user knows the position. Does it really need any more explaining? Integrating a feature like this to EAC would truly revolutionize exact ripping. Offset-impaired rips could be fixed as well.

The patches would really be too big, as it's only a matter of - maybe a few thousand samples. I'm not asking for a patch database hosted by EAC.de as it might consume too much bandwidth, the feature itself would already be a bliss. I wouldn't mind if someone started a patch server though.


Story 6) And a few more things about AccurateRip to go:[/u]
- If an EAC user rips a CD that isn't in the DB, a deep recommendation about using Test & Copy and NO C2 should be displayed. It would be pretty nice to having the values right already the first time the CD's ripped.



Wheeew...  Hope I made it readable.

"A few" EAC improvement suggestions

Reply #1 –
As for #5, you can get a binary diff of the two files and patch yours. A tool like Unison can do this over a network easily.

"A few" EAC improvement suggestions

Reply #2 –
For story 1:

The other night the first and last track results for every disc in the database were removed - the reason being AccurateRip has a new hash calculation for the first and last track that skips 5 sectors from the beginning and end of a disc. This is needed for drives that cannot overread and will give the same results regardless of drive - it was the best way to solve that problem.

Story 2: CRC32 is not the best, but it does in theory give a 1:4 Billion error, it was chosen to keep the server database as small as possible.

Story 3: The idea behind AccurateRip is that anyones results are good results - even if they had a drive incorrectly configured with cache, once there are 3 results submitted for any track you will pretty much know if your rip is correct.

The patching idea is interesting, in theory you could do it for any file type, you would need a program that P2P connected to another machine that you knew had the perfect copy.

I want to write some kind of database into accuraterip, that is if you rip a file, but it is not in the database, then it can be checked at a later time when perhaps it is in the database without the need for re-ripping.

"A few" EAC improvement suggestions

Reply #3 –
The first suggestion sounds like something the RIAA's lawyers would drool over--the implementation of a UNCHANGEABLE log gives the impression that you're definetly going to share it, legally or not. (I may be totally off-base, but it's not that wild an assumption). EAC is an amazing resource(that just took a step in the opposite direction with the TOC feature), but to add something designed for the benefit of another user's satisfaction with your cd at this stage in the intellectual property game puts the developer and his great program just a little closer to an annoying lawsuit-look at clonecds original company.

I may be unfairly judging this suggestion, but I know I don't need that feature, and its actual implementation could have some nasty reprecussions-James

"A few" EAC improvement suggestions

Reply #4 –
Quote
Story 2) Hashes (Checksums) to verify file integrity:
[/u]
This one will be a bit shorter:

As far as I know, CRC32 isn't really the most secure checksum algorithm there is. So it would be great to be able to make a choice between, let's say CRC32, MD5 and SHA-1. At least MD5 is extremely fast on my XP1800+. SHA-512 support would be cool too, even though it's a little slower than the others.

To start with, MD5 and SHA-1 aren't even checksum algorithms. They are cryptographic signature algorithms.

And while CRC32 was developed to be able to detect if something got changed inside the file, MD5 and SHA-1 were developed to avoid tampering (I.E artificially creating a string or data chunk that outputs the same signature).

Besides, there's nothing wrong with CRC32 as it is. If you have one byte gone wrong, it will detect. If you have two bytes gone wrong, it MIGHT not detect, but you must be very unlucky to have the exact wrong byte at an exact position.

Last but not least, cryptographic sigs are overkill for that purpose.

"A few" EAC improvement suggestions

Reply #5 –
Quote
Last but not least, cryptographic sigs are overkill for that purpose.

Right...they're one-way hashes and not really intended for these purposes. I think CRC32 is more than sufficient.

"A few" EAC improvement suggestions

Reply #6 –
I have one suggestion.

Current version doesn't allow me using the characters which contain \ (0x5C) in the 2nd
byte of Shift-JIS for file name.

EDIT:typo