05.10.2003, 14:28
Moinsen!
Da es bei den grossen MP3-Album-Releasern (Aggressive Music Ripping Crew, Team Escape, Satanic Supremacy, Gravewish etc.) ueblich ist, eine SFV Datei zu den MP3s und dem Rest dazuzupacken, diese aber nur die gesamte CRC32 ueber eine Datei bildet, ist es mal wieder das alte Problem: Sobald ich was an den Tags aendere, ist schluss mit lustig und der Hash aendert sich.
Nun ist es nicht besonders schwierig, ein System zu erschaffen, welches diese Probleme umgehen wuerde. Eine SFV-Datei enthaelt Dateinamen und CRC32 in einer Liste. Jetzt gibt es da schon so ein Ding, welches bei MP3s nur die Audioframes nimmt, einen Hash erstellt und den in den ID3v2 reinpackt. Ist aber auch nicht das wahre.
Mein Vorschlaeg waere nun ein SFV-Derivat, welches so aussieht:
00-dateiname.mp3 1 00 2000 fff865347676ac0000143f7cee 478abc fa78cd1f
Zeilenformat:
- Dateiname
- Anzahl Bloecke (1; koennen beliebig viele sein, aber in der richtigen Reihenfolge)
- Blockstatus (00; kann aussagen, ob der Block zwingend vorhanden sein soll bzw. ob die Daten veraenderlich sind)
- Blockoffset (urspruengliche Stelle, an der dieser Block innerhalb der Datei anfaengt)
- Blockanfangsdaten (also ein paar Hex-Bytes, nach denen in der Datei gesucht wird)
- Blockgroesse (Hex)
- Block-CRC32 (8-stellig Hex)
Das Ding soll EFV (Extended File Verificator) heissen, womit es dann moeglich waere, MP3s auf Konsistenz zu ueberpruefen und evtl. Tags dabei zu ueberspringen.
Denkt man hierbei einen Schritt weiter, so ergibt sich eine Moeglichkeit, einen gut strukturierten Nachfolger fuer das Tool RCAM zu basteln. Quasi einen EFV->ZIP Konverter, der anhand der EFV-Datei ein ZIP-Archiv erstellt welches sich dann wie bei RCAM nach dem Entpacken rekonstruieren laesst.
Bloecke mit Status 01 (z.B.) koennten aussagen, dass sie veraenderlich sind. Das wuerde auf z.B. Tags zutreffen. Deren Inhalt koennte dann mit in die EFV-Datei geschrieben werden, so dass sich die Dateien notfalls wieder so rekonstruieren lassen, dass die urspruenglichen Tags wieder drin sind.
Ich will mich jetzt hier nicht selbst anpreisen, aber ich hasse es, wenn es Provisorien dazu bringen, als Standard genutzt zu werden. SFV ist wirklich etwas feines, aber einfach nicht flexibel genug. Ich wuerde mich gerne darum kuemmern, dieses EFV-System zu programmieren, aber auf keinen Fall, wenn die Chancen zu schlecht stehen, dass es auch genutzt wird.
Da das System sehr einfach gehalten ist (vom Aufbau her) und der EFV->ZIP Konverter eben Archive erstellt, die reine ZIP-Dateien sind (wobei man sich auf eine Kompressionsstufe einigen muss und darauf, dass nur eine bestimmte ZLIB-Version benutzt werden darf), duerfte es schonmal hier besser ankommen als das alte RCAM. Ausserdem besteht Hoffnung (die ihr bitte einschaetzen sollt), dass EFV auch von anderen Leuten, vielleicht sogar von den grossen Albumreleasern genutzt wird, und damit das System moeglicherweise sogar fuer Linux programmiert wird.
Jaja, ich weiss, das hoert sich alles Groessenwahnsinnig an. Aber ich bin halt jemand, der sich mit Standards nicht zufrieden gibt, sofern sie nicht perfekt sind. Ich spreche vor allem auch XcalibuR an, wenn ich darum bitte, mir zu sagen, was ihr davon haltet.
Da es bei den grossen MP3-Album-Releasern (Aggressive Music Ripping Crew, Team Escape, Satanic Supremacy, Gravewish etc.) ueblich ist, eine SFV Datei zu den MP3s und dem Rest dazuzupacken, diese aber nur die gesamte CRC32 ueber eine Datei bildet, ist es mal wieder das alte Problem: Sobald ich was an den Tags aendere, ist schluss mit lustig und der Hash aendert sich.
Nun ist es nicht besonders schwierig, ein System zu erschaffen, welches diese Probleme umgehen wuerde. Eine SFV-Datei enthaelt Dateinamen und CRC32 in einer Liste. Jetzt gibt es da schon so ein Ding, welches bei MP3s nur die Audioframes nimmt, einen Hash erstellt und den in den ID3v2 reinpackt. Ist aber auch nicht das wahre.
Mein Vorschlaeg waere nun ein SFV-Derivat, welches so aussieht:
00-dateiname.mp3 1 00 2000 fff865347676ac0000143f7cee 478abc fa78cd1f
Zeilenformat:
- Dateiname
- Anzahl Bloecke (1; koennen beliebig viele sein, aber in der richtigen Reihenfolge)
- Blockstatus (00; kann aussagen, ob der Block zwingend vorhanden sein soll bzw. ob die Daten veraenderlich sind)
- Blockoffset (urspruengliche Stelle, an der dieser Block innerhalb der Datei anfaengt)
- Blockanfangsdaten (also ein paar Hex-Bytes, nach denen in der Datei gesucht wird)
- Blockgroesse (Hex)
- Block-CRC32 (8-stellig Hex)
Das Ding soll EFV (Extended File Verificator) heissen, womit es dann moeglich waere, MP3s auf Konsistenz zu ueberpruefen und evtl. Tags dabei zu ueberspringen.
Denkt man hierbei einen Schritt weiter, so ergibt sich eine Moeglichkeit, einen gut strukturierten Nachfolger fuer das Tool RCAM zu basteln. Quasi einen EFV->ZIP Konverter, der anhand der EFV-Datei ein ZIP-Archiv erstellt welches sich dann wie bei RCAM nach dem Entpacken rekonstruieren laesst.
Bloecke mit Status 01 (z.B.) koennten aussagen, dass sie veraenderlich sind. Das wuerde auf z.B. Tags zutreffen. Deren Inhalt koennte dann mit in die EFV-Datei geschrieben werden, so dass sich die Dateien notfalls wieder so rekonstruieren lassen, dass die urspruenglichen Tags wieder drin sind.
Ich will mich jetzt hier nicht selbst anpreisen, aber ich hasse es, wenn es Provisorien dazu bringen, als Standard genutzt zu werden. SFV ist wirklich etwas feines, aber einfach nicht flexibel genug. Ich wuerde mich gerne darum kuemmern, dieses EFV-System zu programmieren, aber auf keinen Fall, wenn die Chancen zu schlecht stehen, dass es auch genutzt wird.
Da das System sehr einfach gehalten ist (vom Aufbau her) und der EFV->ZIP Konverter eben Archive erstellt, die reine ZIP-Dateien sind (wobei man sich auf eine Kompressionsstufe einigen muss und darauf, dass nur eine bestimmte ZLIB-Version benutzt werden darf), duerfte es schonmal hier besser ankommen als das alte RCAM. Ausserdem besteht Hoffnung (die ihr bitte einschaetzen sollt), dass EFV auch von anderen Leuten, vielleicht sogar von den grossen Albumreleasern genutzt wird, und damit das System moeglicherweise sogar fuer Linux programmiert wird.
Jaja, ich weiss, das hoert sich alles Groessenwahnsinnig an. Aber ich bin halt jemand, der sich mit Standards nicht zufrieden gibt, sofern sie nicht perfekt sind. Ich spreche vor allem auch XcalibuR an, wenn ich darum bitte, mir zu sagen, was ihr davon haltet.