Andre Wiethoff

Done, %V = Artist field...

cu, Andre

kockroach

Awesome, thanks Andre!

kockroach

skolnick

I would like the option to remove the bar on the left side, the one with the four buttons (which I have never used). Also very useful, would be the option to add shortcuts to this bar (like create compressed image+cue, which I use all the time).

Thanks

greynol

Could "Null samples used in CRC calculations : Yes/No" be added to the logfile?

Grey

I'd like to see Accurate Rip results appended to the end of the log file, or written to a separate file.

If the confidence is 0, or my disc is a different pressing, I'd rather not have the Accurate Rip results in my log file.

Lund

What's wrong with the current redundancy check? SHA is a cryptographic type hash function, isn't that overkill?

It makes sense to use SHA-1 and the likes when it comes to validating sensitive data like executables or documents, but audio files?

In case there are no imminent reasons to replace it then I suggest that you don't change it. It would break "backwards compatibility" with older rips, if you replace the CRC in the logs with a new kind of checksum. So making the old CRC at least optional in a future version ("also add CRC checksum to log") should be a must.

Lund

Another feature request.

When creating single WAV image rips, could you add support for embedding cue sheets and EAC logs after compression?

So writing those two into files could be optional, as could be writing them into the tag. This turns rips into very handy single files. And after each rip is done there's only one file left (if the user doesn't want cue sheet and log to be written to files).

The standard tag field name for the cue sheet is CUESHEET, but I don't think there's a standard for EAC logs since it's not essential to have this log for playback... maybe EACLOG? LOG is a bit too ambigous.

Winnie W.

CRC32 is theoretical only a reliable checksum for a amount of data up to 256 MiB, but a CD Image can consist of up to 800 MiB of data.

Maybe, a MD5 checksum is the better choice because it is faster than SHA und more than good enough for that purpose.

Probably, a solution to this is to use CRC32 only for single tracks and MD5 only for CD Images.

Andre Wiethoff

I am not sure which tags you refer to, but ID3 tags have a special field MCDI for the cue sheet (or better the TOC fields). Of course track naming and indecies are lost...

cu, Andre

aSceT

I'll start from one small but extremely useful request:

make all LOGs and CUEs created in UTF-8 format instead of ANSI.
This will allow all logs and cues be properly viewable on every system not depending on its language

Lund

Oh, I'm talking about APEv2 tags, of course. All tag field names are "custom" with APEv2 and the quasi-standard supported by all players with embedded cue sheet support is "CUESHEET". I don't think ID3 is very common with lossless audio formats. IMHO, it makes no sense to rip to single MP3 file + cue sheet anyway... besides doesn't ID3v2 support custom tag field names, too?

FLAC tags has also a special field for cue sheets... but it could also hold the cue sheet in a custom tag field with the name "CUESHEET".

@aSceT: 1+ for UTF-8 output

greynol

IIRC, flac's special field for cue sheets discards all non-01 indices as well as other information that is not relevant to seeking/splitting on standard track boundaries.

I'm opposed to UTF-8 output unless it is made optional. Simply replacing ANSI will undoubtedly force some to have to convert in the other direction. Providing the option to choose would please the greatest number of people; trust me on this.

Lund

Ah, thank you. I could faintly remember something about a flaw in CRC-32, but I didn't find anything about it before I posted my message.

I agree, I think MD5 is pretty decent. Although you can see many download pages shifting from MD5 to SHA-1 when it comes to provide a checksum of the downloads, and there definitely is a collision-problem with MD5, I'm not sure whether the reason for the shift to SHA-1 is because of an unintentional (worse in case of EAC) or intentional collision weakness.

No! I think the old CRC-32 hash algorithm should be made optional for both tracks and images. If images are left out then comparing new rips to old rips using the CRC-32 checksum would be impossible, which exactly is the bad thing I'm concerned about.

The the new hash algorithm should be made mandatory, of course, no option to turn it off.

Ah, I see. Thanks for the warning. For playback purposes this is sufficient, but I'm not only saving the cue sheet into the tag for playback purposes, but to preserve an identical copy of the CD without having to store the cue sheet in a seperate file. So this FLAC internal tag field is not an option for me.

Andre, in case you're planning to implement embedding cue sheets (and EAC logs), it would be nice to warn the user in case he is attempting to save the track list solely into a format where the original layout of the CD gets lost.

I agree, make it optional in some sort of way.

Winnie W.

I wouldn't call it a flaw. It would say it is a (math) limitation of the algorithm.
CRC32 is still not entirely useless for large amounts of data, because CRC32 can always detect some types of error, but probably fails to detect other types of errors (eg. burst errors). Unfortunaly burst errors are the most common type of error occuring at reading dirty or scratched audio CDs.
For large amount of data there is a certain probablity of undetected errors.

MD5 is still secure to detect errors that occurs randomly. However, SHA-1 protects better against intentional alteration of data, but you need a brute force attack to find two different blocks of data with matching checksum.
Using MD5 the probability of randomly matching checksums (despite different data) is so tiny, in reality you would call that chance zero.

If I'm right, CRC32 is still needed to compare ripps using AccurateRip. But I'm not sure if this only concerns individual tracks or all checksums. Whether the checksum of the entire CD image is of importance to AccurateRip, I don't know.

CRC32 of separate tracks is required by AccurateRip. Maybe, an other checksum provides more reliability, but CRC32 can't be droped. Because most tracks on audios CDs don't exceed 256 MiB of data, I think an additional or alternative checksum for individual tracks should be optional.
But the Checksum for entire disks should be changed to MD5 (or comparable), because of the higher probabilty of undetected errors. Perhaps both checksums for CD images, CRC32 (to stay compatible to ripps of older versions of EAC) and MD5.

greynol

AccurateRip has its own method of calculating checksums which is not CRC32. AR checksums are completely independent of EAC checksums. In fact, EAC doesn't even have to calculate checksums for AR to work.