DT Lite 4.41.3 öffnet CUE von EAC 1.0b2 nicht

[LigH]

Wenn ich versuche, ein Audio-CD-Image zu öffnen, das gerade eben unter Windows XP SP3 mit EAC 1.0b2 erzeugt wurde, bekomme ich lediglich die knappe Meldung:

---------------------------
DAEMON Tools Lite
---------------------------
Image konnte nicht eingebunden werden. 
---------------------------
OK   
---------------------------

An den Indizes sollte es nicht liegen, denn es wird eine WAV-Datei für die gesamte Disk verwendet (Probleme gab es nur bei WAV-Dateien pro Track, wenn Pausen und Dateiangaben nicht in kompatibler Reihenfolge standen).

Vielleicht verwendet EAC 1.0b2 nun wieder mal zusätzliche Einträge, die DT Lite nicht ignoriert, obwohl es sie nicht kennt?

REM GENRE Hi-NRG
REM DATE 1993
REM DISCID 9E0E1A0D
REM COMMENT "ExactAudioCopy v1.0b2"
CATALOG 0000000000000
PERFORMER "Frankie Goes to Hollywood"
TITLE "Bang! - The Greatest Hits"
FILE "Frankie Goes to Hollywood - (1993) Bang! - The Greatest Hits.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Relax"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801204
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Two Tribes"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801205
    INDEX 00 03:55:09
    INDEX 01 03:56:52
  TRACK 03 AUDIO
    TITLE "War"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801206
    INDEX 00 07:51:54
    INDEX 01 07:53:05
  TRACK 04 AUDIO
    TITLE "Ferry Cross the Mersey"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801207
    INDEX 00 12:07:56
    INDEX 01 12:08:72
  TRACK 05 AUDIO
    TITLE "Warriors of the Wasteland"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801208
    INDEX 00 16:13:06
    INDEX 01 16:14:50
  TRACK 06 AUDIO
    TITLE "For Heaven's Sake"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801209
    INDEX 00 20:09:64
    INDEX 01 20:11:05
  TRACK 07 AUDIO
    TITLE "The World Is My Oyster"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801210
    INDEX 00 24:38:56
    INDEX 01 24:40:15
  TRACK 08 AUDIO
    TITLE "Welcome to the Pleasuredome"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801210
    INDEX 01 26:38:02
  TRACK 09 AUDIO
    TITLE "Watching the Wildlife"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801212
    INDEX 00 40:18:65
    INDEX 01 40:19:02
  TRACK 10 AUDIO
    TITLE "Born to Run"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801213
    INDEX 00 44:17:09
    INDEX 01 44:18:55
  TRACK 11 AUDIO
    TITLE "Rage Hard"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801214
    INDEX 00 48:25:13
    INDEX 01 48:25:17
  TRACK 12 AUDIO
    TITLE "The Power of Love"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801215
    INDEX 00 53:30:31
    INDEX 01 53:31:35
  TRACK 13 AUDIO
    TITLE "Bang"
    PERFORMER "Frankie Goes to Hollywood"
    ISRC TbBBJ9801216
    INDEX 00 59:00:55
    INDEX 01 59:02:07

In solchen Fällen wäre sicherlich hilfreich, wenn die Fehlermeldung noch ein paar Details aus dem CUE-Parser anzeigen würde, um die Ursache näher einzugrenzen.

[LigH]

Und schon kann ich den Beitrag nicht mehr bearbeiten, um noch was anzufügen ... na gut, dann antworte ich mir eben selbst:

Vermutlich liegt es an den nicht ganz als Hexcode tauglichen ISRC-Einträgen. Lösche ich die heraus, kann DT Lite die CUE öffnen.

Eine andere CUE, bei der ISRC-Einträge als Hexadezimal gültig wären, wird auch geöffnet:

REM GENRE Techno
REM DATE 1999
REM DISCID 3606BF04
REM COMMENT "ExactAudioCopy v1.0b2"
PERFORMER "GiGi D'Agostino"
TITLE "Bla Bla Bla"
FILE "GiGi D'Agostino - (1999) Bla Bla Bla.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Bla Bla Bla (Radio Cut)"
    PERFORMER "GiGi D'Agostino"
    ISRC DEA319903669
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Bla Bla Bla (Abbentenza Mix)"
    PERFORMER "GiGi D'Agostino"
    ISRC DEA319903670
    INDEX 00 03:14:11
    INDEX 01 03:16:17
  TRACK 03 AUDIO
    TITLE "Bla Bla Bla (Africanismo Mix)"
    PERFORMER "GiGi D'Agostino"
    ISRC DEA319903671
    INDEX 00 10:12:06
    INDEX 01 10:14:12

Laut Wikipedia: ISRC (deutsch / englisch) ist das auch kein Hexadezimal-Code, sondern speichert u.a. Herkunftsland (ISO 3166-1 alpha-2) und Hersteller. Ob das kleine "b" schuld ist, werden hier nur Großbuchstaben erwartet?

[LigH]

In der Tat: Wenn ich "Tb" zu "TB" ändere (nur Großbuchstaben und Ziffern in den ISRC-Angaben), akzeptiert DT Lite die CUE-Datei.

[LigH]

Ja, und ... nun?!

Interessiert das jemanden in der Entwicklung? Irgend eine Antwort wie "Gut, wir prüfen mal den CUE-Parser"?

...

In der Zwischenzeit ist mir noch eine CUE-Datei mit ähnlichen Problemen untergekommen:

REM GENRE Hip-Hop
REM DATE 2008
REM DISCID 0611BE12
REM COMMENT "ExactAudioCopy v1.0b2"
PERFORMER "Thomas D"
TITLE "Kennzeichen D"
FILE "Thomas D - (2008) Kennzeichen D.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Deshalb bin ich hier"
    PERFORMER "Thomas D"
    ISRC DEJC:0800001
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Get On Board"
    PERFORMER "Thomas D"
    ISRC DEJC:0800002
    INDEX 00 03:19:19
    INDEX 01 03:21:19
  TRACK 03 AUDIO
    TITLE "Keine Panik (Der Handtuch Song)"
    PERFORMER "Thomas D"
    ISRC DEJC:0800003
    INDEX 01 06:59:02
  TRACK 04 AUDIO
    TITLE "15 Min. Of Fame"
    PERFORMER "Thomas D"
    ISRC DEJC:0800004
    INDEX 00 10:38:08
    INDEX 01 10:39:69
  TRACK 05 AUDIO
    TITLE "Fluss"
    PERFORMER "Thomas D"
    ISRC DEJC:0800005
    INDEX 00 14:52:48
    INDEX 01 14:55:23
  TRACK 06 AUDIO
    TITLE "Die Stadt schläft"
    PERFORMER "Thomas D"
    ISRC DEJC:0800006
    INDEX 00 19:39:15
    INDEX 01 19:41:02
  TRACK 07 AUDIO
    TITLE "Wir brauchen dich"
    PERFORMER "Thomas D"
    ISRC DEJC:0800007
    INDEX 00 23:26:04
    INDEX 01 23:28:04
  TRACK 08 AUDIO
    TITLE "Rennen"
    PERFORMER "Thomas D"
    ISRC DEJC:0800008
    INDEX 00 26:42:09
    INDEX 01 26:44:39
  TRACK 09 AUDIO
    TITLE "Thank U For The Music"
    PERFORMER "Thomas D"
    ISRC DEJC:0800009
    INDEX 00 30:50:25
    INDEX 01 30:52:25
  TRACK 10 AUDIO
    TITLE "Vergiftet im Schlaf"
    PERFORMER "Thomas D"
    ISRC DEJC:0800010
    INDEX 00 35:32:63
    INDEX 01 35:34:40
  TRACK 11 AUDIO
    TITLE "Fighter"
    PERFORMER "Thomas D"
    ISRC DEJC:0800011
    INDEX 00 39:31:11
    INDEX 01 39:33:09
  TRACK 12 AUDIO
    TITLE "Charly Brown"
    PERFORMER "Thomas D"
    ISRC DEJC:0800012
    INDEX 00 43:02:46
    INDEX 01 43:04:69
  TRACK 13 AUDIO
    TITLE "Ride On"
    PERFORMER "Thomas D"
    ISRC DEJC:0800013
    INDEX 00 46:55:30
    INDEX 01 46:57:30
  TRACK 14 AUDIO
    TITLE "Neophyta"
    PERFORMER "Thomas D"
    ISRC DEJC:0800014
    INDEX 00 50:55:05
    INDEX 01 50:57:46
  TRACK 15 AUDIO
    TITLE "Der eine Schlag"
    PERFORMER "Thomas D"
    ISRC DEJC:0800015
    INDEX 00 55:20:18
    INDEX 01 55:22:05
  TRACK 16 AUDIO
    TITLE "Symphonie der Zerstörung"
    PERFORMER "Thomas D"
    ISRC DEJC:0800016
    INDEX 00 60:42:15
    INDEX 01 60:44:57
  TRACK 17 AUDIO
    TITLE "An alle Hinterbliebenen"
    PERFORMER "Thomas D"
    ISRC DEJC:0800017
    INDEX 00 64:51:61
    INDEX 01 64:54:11
  TRACK 18 AUDIO
    TITLE "Vergebung hier ist sie"
    PERFORMER "Thomas D"
    ISRC DEJC:0800018
    INDEX 00 69:41:45
    INDEX 01 69:43:50

Sicherlich ist die Ursache hier der Doppelpunkt.

[Blazkowicz]

http://forum.daemon-tools.cc/f14/daemon-tools-will-not-mount-cue-files-isrc-codes-21667/#post104325

Thread sagt soviel, dass im ISRC nur Gross-Buchstaben und Zahlen vorhanden sein duerfen.

[LigH]

Nun gut; in der Wikipedia darf man sicherlich keine endgültig detaillierten Angaben erwarten. Schade nur, dass viele ISO-Dokumente nicht offen und kostenlos verfügbar sind (hier 66,– Schweizer Franken). Der Hinweis auf das Geltungsjahr (ISO 3901:2001) legt die Vermutung nahe, dass der Standard schon einmal geändert worden ist ... wer weiß, vielleicht ist der Code für die Herstellerfirma mittlerweile nicht mehr ausschließlich auf Ziffern und Großbuchstaben beschränkt. Immerhin existieren ja offensichtlich Pressungen mit solchen ehemals vielleicht nicht konformen ISRC-Einträgen. Und EAC kann die ja auch bloß aus der CD auslesen. Oder?!

Also ob ein nicht konformer ISRC nun ein Grund ist, eine CUE mit (nichtssagender) Fehlermeldung nicht zu laden, wäre für mich ein noch nicht geklärter Streitpunkt. Vielleicht reicht eine Warnung bzw. ein Hinweis; und ganz sicher möchte ich detailliertere Meldungen empfehlen, aus welchen Gründen DT das Laden eines Images verweigert.

[Terramex]

Rein informativ, denn wissen tue ich nix - und ohne Gewähr

RESOURCES - ISRC - Handbook (incorporating the ISRC Practical Guide)

For visual presentation it is divided into four elements separated by hyphens and the letters
ISRC should always precede an ISRC code. The hyphens are however not part of the ISRC.

RESOURCES - ISRC - Handbook (incorporating the ISRC Practical Guide)

Where computer software displays an ISRC it should separate the
four elements with hyphens (see Section 3.5.1 General ).
Unless the context makes this unnecessary (such as tabular presentation) it should
precede the code with characters ‘ISRC.
Where computer software accepts input from a user, it can helpfully accept the four
elements and present these to the users with their separating hyphens.

Was mögliche Restriktionen in einer CUE angeht habe ich nur das gefunden:
digitalx.org � Cue-Sheet Syntax

Chapter*6.*Exporting

...A valid ISRC is all capitals, 12 characters.

Dessen ungeachtet könnte man am Parser schon was ändern - andere Programme schlucken solche
CUEs ja auch indem sie den Fehler einfach ignorieren und den ISRC Part nicht verwerten, z.B ImgBurn.
Und falls nicht, weisst du jetzt ja woran es scheitert

EDIT:
der CD Layout Editor von EAC sagt bei mehr als 12 Zeichen übrigens:

Error in CUE sheet !
ISRC string has wrong length in line x

[LigH]

Mehr als 12 sind's ja nicht; nur eben "nicht nur Großbuchstaben".

Genau um den Kern geht es mir: Etwas toleranterer Umgang mit eigentlich unkritischen Fehlern. Und vielleicht etwas mehr Details, wenn es doch mal kritisch ist.

[Blazkowicz]

Ueber den Aufbau von ISRC:
ISRC - International Standard Recording Code
Ich gebs weiter, dass eine Warnung angezeigt werden soll, ob es umgesetzt wird, ist allerdings etwas anders.

[LigH]

Dafür zumindest ein Dankeschön.

[cs_gabriel]

wird doch eh nur als string oder ähnlich eingelesen, wie wäre es an der stelle einfach eine autokorrecktur einzusetzen.

also nach dem einlesen denstring z.b. durch :

#include <string.h>

char *strupr(char *s);

auf großbuchstaben umwandeln.

danach kann der doch ganz simpel, durch den rest ohne änderung weitergereicht werden.

[LigH]

Habe gerade noch einen älteren Hinweis (von 2009) im EAC-Forum gefunden:

EAC retrieves corrupted ISRC codes

Anscheinend liefert die Firmware mancher Laufwerke nicht die korrekten Daten; CDRDAO greift auf "tiefere" (hardwarenähere) Funktionen zu und kann die korrekten ISRC-Werte aus den Sub-Channel-Daten auslesen, während EAC sich auf andere APIs verlässt, die sich wohl nur um die Nutzdaten sicher kümmern.

[Terramex]

Unabhängig davon was die DT Entwickler anders/besser machen könnten um die Fehler anderer auszumerzen:
Jetzt da du die Ursachen kennst, ist es dir da in den Sinn gekommen auch im EAC Forum zu fragen, ob man
von deren Seite aus etwas anders gestalten könnte ? z.B. nicht der Norm entsprechende bzw. falsche
ISRC codes nicht zu übernehmen, oder den Benutzer wenigstens auf den Fehler hinzuweisen
Vielleicht auch mal LiteOn anschreiben, ob sie das mit einem Firmware-Update beheben können.

Auch ImgBurn z.B. liest mit Hilfe der Subchannel-Daten die ISRC codes korrekt aus mit dem iHAS 124 A.
Bad or no ISRC and MCN codes from CD audio discs - ImgBurn Support Forum

EAC:

...
FILE "01 Track01.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Track01"
    PERFORMER "Unknown Artist"
    ISRC TbBKT9800039
    PREGAP 00:00:32
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Track02"
    PERFORMER "Unknown Artist"
    ISRC TbBKT9800060
    INDEX 00 04:33:18
FILE "02 Track02.wav" WAVE
    INDEX 01 00:00:00
  TRACK 03 AUDIO
    TITLE "Track03"
    PERFORMER "Unknown Artist"
    ISRC TbBKT9800061
    INDEX 00 03:20:23
FILE "03 Track03.wav" WAVE
    INDEX 01 00:00:00

ImgBurn

FILE "Image.WAV" WAVE
  TRACK 01 AUDIO
    ISRC GBBKT9800039
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    ISRC GBBKT9800060
    INDEX 00 04:33:50
    INDEX 01 04:35:27
  TRACK 03 AUDIO
    ISRC GBBKT9800061
    INDEX 00 07:55:50
    INDEX 01 07:56:30

[LigH]

Ja, klar hab ich bei EAC auch das Problem noch mal angemerkt; aber ich weiß ja, wie lange und erfolglos man auch dort manchmal seine Meinung vertreten kann...

Im Grunde wäre müsste man da ja auch die Meinung vertreten: "Entweder ganz richtig oder gar nicht." Klar, ich kann auch das Auslesen des ISRC gleich komplett abschalten, wenn's eh nicht mit jedem Laufwerk zuverlässig funktioniert.

Aber wenn A.W. schon (seit mindestens 2009) weiß, dass es mit anderen Zugriffsmethoden korrekt funktionieren würde, dann kommt heute die Frage "Warum implementierst du sie dann nicht?" auch nicht gerade kreativ daher.

Und ob es was nützt, LiteOn anzuschreiben, ist auch insofern fraglich, als dass deswegen vermutlich die Firmware von Auslaufmodellen auch nicht noch mal überarbeitet werden wird.

[Terramex]

Und ob es was nützt, LiteOn anzuschreiben, ist auch insofern fraglich, als dass deswegen vermutlich die Firmware von Auslaufmodellen auch nicht noch mal überarbeitet werden wird.

Zugegeben war da jetzt auch etwas Ironie im Spiel.
Vielleicht macht es ja für zukünftige Modelle Sinn.
Meine Zuversicht ist hier ehrlich gesagt aber auch eher gering
Lassen wir uns mal überraschen welchen Platz dein Anliegen auf der Dämonen-Prioritätsliste einnimmt.