Thread: Why I hate EAC---Malformed CUE sheets

Originally Posted by germ

Max could improve in its ability to handle malformed CUE sheets,

Yes they could, and the fact that they did not clearly says that they are responsible for what and how Max works or in this case how it fails.
How many cue sheets did you try before you realized that something was wrong? Did anyone at Max do any real world testing?

The solution is very simple code.
As posted before in this thread, You can see it in action here.
http://eachelper.uphero.com/cue2cuehtml.php

Someone should ask Stephen. He's a nice guy and quite responsive.

I've never used Max, but it seems quite odd that it would require let alone encourage someone to use a CUE sheet to perform a conversion on tracks as individual files. For a single-file image this is completely understandable, but for one track per file I'm more than a little suspicious that this is the way it was intended to be used.

One word from me (before we all hopefully stop arguing whether I should stop this or not - because I wouldn't ) :

I can understand that there are people arguing against the extension of the CUE format. I know that Joerg Schilling also will do something about CUE sheets in CDRecord. We had some discussion and he plans to use his own extensions, which are "enabled" and used in the CUE sheet comments (which is a way to maintain compatibility, but also beeing able to process the additional information in his -or compatible- programs).

Once (the first versions of EAC) supported an own "CUE" format with the extension ".elf". Nobody used it, everybody used the CUE Sheets. After a time, I throwed out the .elf support...

Anyway, the reason I just extended the CUE sheet format were:

1) To the time I implemented CUE sheet support, CDRWin (and CUE sheets) seemed pretty dead - it might be different in different countries, but here it was that nearly no program was creating or working with CUE sheets (some burning programs had writing support for image files + CUE sheets, besides 1000s of different image formats)...
2) The CUE sheet "standard" was not well written (even worse than ID3V2.3 tagging standard), so I thought a small relaxation of the standard wouldn't hurt (but help quite much)
3) I was young, perhaps I would do an own format nowadays (and only produce "compatible" CUE sheets) - of course it is now too late, too many existing CUE sheets are around...

I gave the relaxation of the standard a great time of thinking, and the only real relaxation is that a FILE statement can now be at any position (before any INDEX position). This helped to make ANY possible file/disc combination possible.

The reason why it is not a good idea to rip that the CUE sheets are compliant is the following: Assuming that you still want to rip track based (and don't just want to drop/delete the gaps) is to rip INDEX 00 and then INDEX 01. This would result in audio files which would start with usually around 2 seconds of silence. Of course, if you just want to use the resulting files to burn an exact copy of the CD, that would be no problem. But usually people want to archive their CDs AND to listen to the tracks on MP3 players or music system in their home. Therefore it is no alternative to rip tracks with "corrected gaps".

Of course this is only my opinion, nobody need to work with EAC CUE sheets, but all programs should note : "The CUE Sheet is not compliant - I will not work with this!" and everything is fine. People will have a look around, learn, and finally reading the textual CUE Sheet and find out that it is created by EAC... Or Just burn the individual files! Not optimal, but working.

Anyhow, I can not understand parser programmers who don't want to read extended files (as it is a superset of CDRWins CUESheeet, so every "compliant" CUE sheet is still be read completely fine). Of course any really malformed CUE sheet might come through - but be honest, how many really malformed CUE sheet (which disobeyed the given relaxation) did you really encounter?

Finally, CUE sheets (in combination with images or files) were thought to support users for backup purposes - not for sharing music on the internet. In the first case, there is no compatibility problem - they know exactly that EAC created the CUE sheet and that EAC will read the CUE sheet again. If there are problems, they can find plenty of help in the forum or in the mailing list...

Regards,

Andre

I have just one question:

Why do you capitalize CUE?

Thank you all, very informative reading. Remains only to quote classics - "quot homines, tot sententiae." I personally use cue-sheets only for burning CDs.

I just want to point out, just because some people (ie. old men in a conference room) write a "standard" about a file format doesn't mean it's some universal law that can never be changed or violated. EAC extended the CUE standard because it was required to add an important functionality. If resulting sheets can't be used with some other software then users just have to pick between EAC or the other. Suck it up....