Info: Technisches zur CD-Kartei

 

Hallo

Was man hier sieht ist eine Darstellung meiner CD-Kartei. Aus Interesse an der Programmierung von Datenbanken hatte ich Ende der 80er Jahre damit angefangen, meinen Bestand an CDs auf dem Computer zu erfassen. Zuerst als lineare dBase Liste, was aber bald an die Grenzen stiess. Deswegen kam es dann zu einem Umstieg auf eine relationale Datenbank. Die Datenbank selber war - und ist bis heute - Paradox von der Fa. Borland. Das Front-End war anfänglich ObjectVision von Borland, eine Speziallösung, die bald vom Markt verschwand. Da bot sich der Umstieg auf Delphi an. Und dabei ist es bis heute geblieben.

Relativ schnell wuchs die Sammlung, und der Überblick ging irgendwie verloren, zumindest in meinem Kopf. Beim Jagen und Suchen in den Läden kam es immer wieder vor, dass ich mit einer Aufnahme nach Hause kam, um festzustellen, dass ich sie schon hatte. Nur hatte der Vertrieb oder der Verlag oder wer auch immer das Cover für die Wiederveröffentlichung neu designed. Deswegen die Suche nach einer Möglichkeit, die Kartei mitzunehmen, um gleich nach Aufnahmedatum und sowas nachschlagen zu können. Der Papierstapel war deftig. Aber zur gleichen Zeit kam mein erster Organizer: ein Psion. Konnte nur lineare Datenbanken, aber eine geschickte SQL Abfrage in Paradox erzeugte die notwendige Tabelle.

Leider zog sich dann Psion vom Organizer-Markt zurück, und der gute Psion fing an zu zerbröseln, die flexiblen Leiterbahnen im Scharnier .... Nachfolger: von Palm. System war ähnlich, also eigentlich weiter so wie bisher. Nur hatte der einen Schlitz für Secure Digital Karten. Speicherplatz ohne Ende, das reizte. Es gibt für Palm relationale Datenbanksysteme, aber noch ein Programm mehr, dafür bekommt man auch 5 CDs und so kam der Gedanke, ein sowieso vorhandenes Programm zu nutzen: den Mobipocket Reader. Ein eBook Reader, der auch Nachschlagewerke unterstützt. Zum Erstellen von Büchern gibts ein - für Privatanwendungen kostenloses - Programm, das als Input ein Word-Dokument oder HTML akzeptiert (MobiPocket Creator). Also das Ausdruckprogramm für den Papierausdruck auf die GDI Schnittstelle umgestrickt, ein paar HTML Befehle anstatt GDI Anweisungen, fertig war das mitnehmbare Buch "All My CDs" auf dem Palm.

Wie bei so vielem im Computerbereich wurde auch der Webspace immer billiger, die Flatrate mit DSL war da, und der alte Vertrag wurde beim Provider durch einen Neueren ersetzt: 250 anstatt 30MB Webspace - zu geringeren Kosten. Was soll man nur damit anfangen? Du hast da einen automatischen HTML Generator, der macht dir die Inhalte. Ein bisschen Navigation drum herum gestrickt, also los. Das mit der Navigation war dann doch nicht so einfach, man sieht es den Seiten auch an. Sie sind von Hand gemacht, kein Web-Editor, sie nutzen Frames - was nicht so ganz zeitgemäss und genial ist, aber schön einfach zu schreiben. An manchen Ecken ist es auch nicht optimal zu navigieren - ich weiss - und mit allen möglichen Browsern hab ich auch nicht getestet.

Erster Rückschlag: Auf dem Rechner lokal hatte alles funktioniert, aber dann auf dem Server: Ätsch! Ursache: Gross/Kleinschreibung. Alles noch mal nachbessern. Dann kam der zweite Rückschlag: die Dateigrössen. Vieles besteht aus Tabellen, wie nicht anders bei der Abbildung einer Datenbank zu erwarten. Und in HTML muss man jedes Feld neu formatieren, es gibt keinen Schiften-Tag, der "über alles" wirkt. Das führt dazu, dass teilweise nur ein Drittel Inhalt und ganze zwei Drittel Formatierungsanweisungen waren. Ladezeit über Modem: vergiss es. Als Lösung habe ich CSS genommen: Cascading StyleSheets. Nach einigem vergeblichem Rumprobieren, den Informationen von http://de.selfhtml.org/, viel Programmierarbeit und dem endlichen Verstehen "wie's geht", dank dem Buch CSS-Praxis von Kai Laborenz - Verlag Galileo Computing (mein Urteil zum Buch: sehr empfehlenswert), kam dann was IMHO Brauchbares raus. Nicht wundern, dass die Style-Anweisungen im Dokumentenkopf stehen, und nicht als verlinktes Stylesheets eingebunden sind. Es gibt sie handgemacht trotzdem nur ein einziges Mal und der ganze Salat wird beim Erstellen per meiner Delphi Procedure tFormMain.MachHeaderLines(...); automatisch eingebunden. Irgendwann stell' ich das vielleicht noch mal um.

Ich kann von Unterwegs via Internet nachschlagen, alles Andere ist nur zum Spass und sollte gar nicht in Stress ausarten.

Viel Spass beim Stöbern!

 

Update 25. März 2008

Schon seit einiger Zeit befindet sich auch in meinem Besitz so ein kleiner portabler Audioplayer. Da mir die ganze iTunes-Geschichte nicht wirklich behagt - zu viele Restriktionen - einen iRiver (H320) und als Fileformat OGG Vorbis (*.ogg). Die Klangqualität ist laut meinen Ohren der von Standard MP3 mit konstanter Bitrate überlegen und vor allem, die ganze Sache ist Public Domain und Open Source, da kann einem keiner irgendwelche Rechte nachträglich entziehen. Wer näheres zu OGG Vorbis nachlesen möchte bitte hier lang zur Homepage von Vorbis .

Dann kam noch eine bezahlbare externe 320GiB-USB-Festplatte dazu und eine Soundkarte, die per SPDIF Digitalverbindung den Wandler im CD-Player der HiFi-Anlage direkt speisen kann. Da lag einfach die Idee eines Audioservers nahe. Zuerst ganz einfach nur als Baum abgelegt, Pfad und Dateiname:
[X]:\[Dateiformat]\[Alphabet]\[Interpret]\[Album]\[TitelNr.]&sdot[TitelName].[Erweiterung Dateiformat]

Die Struktur ermöglicht gleich bei der Umwandlung von *.wav in *.ogg per oggDropXPD ein automatisches Tagging der komprimierten Files. Relativ schnell war ein kleines Tool selbst geschrieben, dass die Titelnamen aus der Datenbank übernahm und die vom PlexTools Professional erzeugten Dateien Track[nn].wav automatisch umbenennt. Aber der Appetit kommt mit dem Essen, so auch hier zwei Wünsche:

  1. Registrieren, welche CDs und welche Titel schon auf dem Audio-Server liegen – und wenn schon, dann auch gleich in welchem Format (vorsichtshalber vier, OGG, WAV, MP3, AAC vorgesehen).
  2. Audiodatei gleich aus dem Programm CD-Kartei heraus abspielen können.

Für Punkt 1 war nun eine Erweiterung der Datenbankstruktur notwendig. Am einfachsten wäre es gewesen, zu jedem Datensatz der Tabelle Takes.db 4 Felder für die vier genannten Dateiformate hinzuzufügen und in jedem den kompletten Dateinamen abzulegen. Aber zwei gravierende Nachteile: Der Platzbedarf wäre heftig, was weniger eine Frage des Plattenplatzes ist, aber der Zugriffsgeschwindigkeit. Wichtiger: das Laufwerksmapping und die Verzeichnisse hätten nie ohne komplexen Umstellungsaufwand geändert werden können. Deswegen eine auf den ersten Blick etwas kompliziertere Lösung. Pro Datensatz in Takes.db vier zusätzliche boolsche Felder OGG, WAV, MP3 und AAC. Boolsche Felder sind sehr klein und enthalten nur die Information JA oder NEIN, also hier >Datei im Format soundso vorhanden< oder eben nicht. Zusätzlich ein Feld namens FileName mit Inhalt [TitelNr.]&sdot[TitelName]. Dies ist notwendig, weil die TitelNr fortlaufend ist und nicht wie in Takes.db zweiteilig aus CDNr plus TitelNr zusammengesetzt wird und weil in vielen Titelnamen Sonderzeichen vorkommen, die nicht als Dateinamen zulässig sind. Der Pfad [X]:\[Dateiformat]\[Alphabet]\[Interpret]\[Album]\ wird in zwei Teile geteilt: Der vordere Teil [X]:\[Dateiformat]\ wird als lokales Wurzelverzeichnis auf jedem Rechner abgelegt, auf dem ein Datenbank Client installiert ist. Somit kann jeder PC für die externe Festplatte sein eigenes lokales Mapping verwenden und diese kann gegebenenfalls problemlos schnell und einfach geändert werden. Der hintere Teil [Alphabet]\[Interpret]\[Album]\ wird zu jeder CD einmal in der Tabelle CDDaten.db im Feld FilePath abgelegt. Der Datenumfang reduziert sich so auf rund ein Viertel.

Ein weiterer Trick ermöglicht das parallele Handling mehrerer Dateiformate ohne zusätzliche Felder in parallelen Strukturen. Taucht im Pfad ein Verzeichnis OGG, WAV, MP3 oder AAC auf, so wird dort nur ein * abgespeichert, dass beim Aufruf wieder automatisch durch das jeweils gewählte Dateiformat ersetzt wird. Beispielsweise wird so als lokales Wurzelverzeichnis M:\CDs\*\ abgelegt, was somit zwei getrennte Verzeichnisbäume beschreibt: M:\CDs\WAV\ für WAVE-Dateien und M:\CDs\OGG\ für komprimierte OGG Vorbis Dateien.

Beim Punkt 2, dem Abspielen, war ich etwas fauler. Einen kompletten Mediaplayer selber schreiben sowieso nicht, der Borland Delphi Media Player kann von haus aus *.wav, um die Formate *.ogg und *.mp3 hätte man ihn wohl erweitern können, aber schon bei *.aac wäre Ende der Fahnenstange. Und richtig komfortabel ist er sowieso nicht. Deswegen ein anderer Weg. Ich benutze schon lange als Audio-Player auf dem PC WinAmp von Nullsoft Inc.. Der lässt sich ganz gut über Kommandozeile steuern. Zum Beispiel kann man per Aufruf des Programms >C:\Programme\Winamp\winamp.exe< per Parameter >/ADD "Dateiname"< eine beliebige Audiodatei der aktuellen Playlist anhängen (Die doppelten Hochkomma " sind wichtig, sonst mag er kein Leerzeichen im Dateinamen). Somit ist aus der CD-Kartei heraus nicht nur ein indirektes Abspielen möglich (ein mehrfacher Aufruf von WinAmp.exe startet keine weitern Instanzen, sondern hängt die weitern Dateien einfach hinten an, nur beim ersten Aufruf wird das Programm gestartet), sondern auch das einfache Zusammenstellen von Playlists geht nun!

Somit war eine komplette Integration der neuen Funktionen an den paar Osterfeiertagen möglich, inklusive Registrierung aller rund 300 schon auf dem Audioserver vorhandener Alben. Um ein Album zu registrieren, wählt man es in der CD-Kartei an, um dann per Datei-Öffnen-Dialog einmalig alle zugehörigen Audio-Dateien um Unterverzeichnis auszuwählen. Die Dateien werden dann automatisch nach der TitelNr sortiert, entsprechend zugeordnet und das Format identifiziert.

 

Bild 1: Darstellung der vollständigen Paradox-Datenbankstruktur:

Bild 2: Screenshot des Datenbank Clients (Borland Delphi 4 bis 7):

 

Update 21. August 2008

Man sieht es nicht, aber es hat sich was geändert. Die Frames sind nicht mehr in "HTML 4.0 Transitional" geschrieben, sondern sind jetzt <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">! Anlass war die Überprüfung der Seiten auf korrekte Syntax mittels Tidy und dem Markup Validation Service von w3c. Dabei wurden einige Fehler gefunden deren Beseitigung sinnvoll war. Es ergab sich, dass gar nicht so viel zur Variante "strict" fehlte. Ein Schritt in Richtung XHTML. Das eigentliche Frameset bleibt logischerweise in der Variante "Frameset".

Ärger machten mal wieder die verschiedenen Browser. IE lässt leere Absätze <p></p> einfach weg, macht also keine Leerzeile. Bei der automatischen Generierung muss das Programm also jedesmal überprüfen, ob das Datenbankfeld überhaupt einen Inhalt hat. Wenn nicht, dann darf es keinen Leerstring, also "Nichts" in den Absatz schreiben, sondern muss stattdessen ein geschütztes Leerzeichen <p>&nbsp;</p> einbauen, auch nicht gerade elegant.

Als Belohnung darf sich die CD-Kartei jetzt mit den Prüfsiegeln schmücken:

Frameset: Valid HTML 4.01 Frameset
Strict: Valid HTML 4.01 Strict
CSS: CSS ist valide!

 

Update 18. April 2011

Man sieht es auch diesmal kaum, aber es hat sich wieder was geändert. Der Fortschritt lässt sich manchmal nicht aufhalten, diesmal in form von neuer Hardware. Ein nettes kleines Netbook, und da war dann Windows 7 drauf installiert. Und das hatte seinen eigenen Kopf. Das gute alte Delphi 7 von Borland war unter dem Betriebssystem nicht wirklich hinreichend zum Laufen zu bewegen. Da half alles rumfummeln und klagen nichts, es musste eine neue Entwicklungsumgebung her. Embarcadero Delphi XE nennt sich das jetzt, das ist immerhin abwärtskompatibel, der alte Borland-Quellcode weird beim ersten Öffnen konvertiert. Allerdings kommt dann eine lange Liste Fehlermeldungen. Allerdngs fast immer relativ verständlich und von der Natur, dass dieser Befehl veraltet ist und man besser das moderne .NET-Objekt XYZ verwenden soll. Der Umstellungsaufwand war im Endeffekt nicht so schlimm, trotz deutlich über 12500 Zeilen Quellcode. Was sich über die Jahre nicht so alles ansammelt.

Die andere Änderung war der Bildschirm. Das NetBook hat einen mit 1366x768 Pixel, das bedeutet 16 zu 9, also Breitbildformat. Da war es doch vorteilhafter, die Formulare ein wenig zu verändern, In Richtung breiter, dafür nicht so hoch. Zusammen mit ein paar kleineren Anpassungen wegen der Fenster-Rahmen kam dann das dabei heraus:

Bild 3: Screenshot des Datenbank Clients (Embarcadero Delphi XE):

 

 

 

Ralf Wacker

Im Wiesental zwischen Basel und Feldberg, den 18. April 2011