Export mit Tabellenaufteilung

Hallo.
Ich überlege meine Musiksammlung in eine Datenbank zu exportieren. Dabei gilt ja das Prinzip, große Tabellen möglichst in mehrere kleinere Tabellen umzuwandeln bzw. Infos auszulagern.

MP3TAG exportiert bei CSV pro Datensatz alle Informationen, auch wenn die sich im nächsten Datensatz wiederholen.

Beispiel:
Morning has broken;Cat Stevens;CD-Titel1;Jahr;CD-Infos usw.
Father an sun;Cat Stevens;CD-Titel1;Jahr;CD-Infos usw.

Ich würde jetzt gerne eine Tabelle exportieren, in der statt jedesmal "Cat Stevens" sowie weitere CD-Infos nur eine Zahl geschrieben wird. und eine zweite Tabelle, in der der Zahl die entsprechende CD "Cat Stevens" zugeordnet wird.
Jeder CD soll also eine Nummer zugeordnet werden und die soll in dem Datensatz des Liedstückes stehen.
Kann MP3TAG das?

Ich kann das natürlich in der Datenbank machen (Tabellenerstellungsabfrage, 1:n-Beziehung usw.), dabei dabei sind jedesmal mehrere Arbeitsschritte erforderlich, die sich mit einer gewitzten Exportfunktion bei MP3TAG vielleicht umgehen lassen.
Vielleicht kann man das Feld "CD-Nummer / DISCNUMBER" dafür mit gebrauchen?
Danke

Das ist zwar für das Beispiel richtig, als generelle Aussage ist es aber falsch.
Wenn du schon 1:n-Beziehungen einrichten willst, dann kannst du mit entsprechenden $loop() für jeweils die 1-Seite Informationen genau nur 1x ausgeben.

Wo ich schwarzsehe: es ist zwar möglich, einen %_counter% laufen zu lassen, aber der ist ggf. bei jedem Export für ein Album anders.
Also die ID würde ich von der Datenbank vergeben lassen und dann zurück in die Dateien importieren.

Ja, die ID werde ich über die Datenbank vergeben. Zumal ich den ersten Wert eh vorgeben müsste, weil schon Datensätze in der DB drin sind.
Die 1:n-Beziehung brauche ich ja nur, wenn ich aus der großen MP3Tag-CSV mehrere Tabellen machen will. Ich weiß noch nicht, ob ich die CSV verknüpfe oder einmalig importiere.

und dann zurück in die Dateien importieren
Du meinst die ID aus der DB in die MP3-Datei importieren? Welchen Vorteil hat das? In meiner Datenbank steht der Pfad zur MP3, das reicht doch als Aufruf.

Naja, wenn du auch nur die kleinste Änderung an den Audiodateien machst, müsstest du die ja erneut importieren. Und damit ginge die gesamte Verknüpferei zwischen ARTIST, ALBUM, TITLE erneut los.
Es wäre da doch viel sinnvoller, die jeweilige ID schon in der AUdiodatei zu speichern und so zu recyclen. Du müsstest dann nur die neuen Stücke verknüpfen, nicht aber die schon bearbeiteten.

Auch könntest du für das Taggen der neuen Dateien wenigstens für ARTIST die Verknüpfungs-ID dann schon aus einer Vorlage-Datei übernehmen.
Oder: wenn du merkst, dass Schreibweisen uneinheitlich (oder sogar falsch) sind, kann es einfacher sein, das in der Datenbank zu bereinigen und über den Import/Export die neuen Daten in den Dateien unterzubringen.
Am Ende würde ich mir überlegen, ob nicht der Dateiname auf die Datenbank-Id geändert wird, um eine eindeutige Zuordnung für den Re-Import zu bekommen.

Das verstehe ich nicht: du musst doch aus so für jede einzelne Datei alle Daten in einer Tabelle hinterlegen - nur dass es dann ggf. nicht der Künstlername in voller Schönheit ist, sondern eben 635897 als ID. Einen Vorteil bringt diese Verknüpfung doch nur dann, wenn du auf diese Weise Schreibweisen vereinheitlichen kannst bzw. so eine Art Referenzkatalog für mögliche Originale hast.
Weitere Beispiele wären ALBUM, GENRE, ALBUMARTIST, COMPOSER.

Du kannst im Daten-Tag der Musikdateien ein Tagfeld anlegen, z. B. CD_NR, und dieses Tagfeld mit einer Nummer füllen, und den Inhalt dieses Tagfeldes mit %CD_NR% exportieren.

Man kann auch direkt die Artikelnummer des Datenträgers erfassen (EAN usw.), z. B. als Tagfeld EAN oder CD_ID, Beispiel: Cat Stevens (EAN 0042284014823 / ID 18850589).

DD.20170626.1151.CEST

Die Daten in der Musikdatei zu speichern dauert aber doch bestimmt sehr lange beim Auslesen? Oder ich verstehe noch nicht ganz was Du meinst.

Ich würde alle Stücke mit MP3Tag taggen und incl. rel. Dateipfad einmalig (!) als csv exportieren. Dann in der Datenbank die CD-Infos rausgefiltert bzw. in eine neue Tabelle gepackt, verknüpft und fertig. Der Player bekommt dann den Pfad übergeben und spielt die Datei ab.
Wenn ich neue Stücke hinzufügen will, muss ich natürlich den Vorgang wiederholen und darauf achten, dass alte Verknüpfungen in der Datenbank erhalten bleiben.

Dann habe ich aber noch keine Tabelle mit den Infos zur CD, sondern nur eine Nummer hinter den Stücken, oder?

Aber die Überlegung, die CDs generell in der DB zu speichern und in MP3Tag nur noch die ID der CD einzugeben ist gut. Aber auch da befürchte ich, das die Abfrage zu lange dauert, wenn die Tags erst von der Datenbank eingelesen werden müssen statt dass sie bereits in einer Tabelle vorliegen. Vielleicht könnte man da mit temporären / Cache-Tabellen arbeiten?
Ich tagge erstmal fleißig weiter und teste dann die Geschwindigkeit der Abfragen.

Ich hatte deine Absichten bisher so verstanden, dass du zusätzlich zur kompakten linearen Verwaltung mit Mp3tag eine unabhängige relationale Datenbank aufbauen und benutzen willst, die aus mehreren Tabellen besteht, die so miteinander verknüpfbar sind, um daraus für jede einzelne Musikdatei einen kompletten Tag-Datensatz zu erzeugen, oder um Auswertungen und Berichte zu erzeugen.
Aus der Verknüpfung mehrerer Tabellen ließe sich so ein kompakter Datensatz wieder herstellen, und der falls notwendig mittels CSV Import und Mp3tag in einen Datei-Tag importiert werden kann.

Die Daten einer CD, also alle Daten, die auf der gedruckten Hülle zu sehen sind oder sonstwie zum Objekt CD dazu gehören, wären dann in den Spalten einer Tabellenzeile oder in den Attributfeldern des Objekts CD gespeichert, eventuell sind daran weitere Untertabellen geknüpft.
Über einen eindeutigen Schlüssel, z. B. die EAN Nummer, könnte man auf diesen Datensatz zugreifen.
Aber warum sollte man einen solchen Aufwand treiben?

Ein ID3 Tag kann doch alle Textdaten speichern, die zu zu einer bestimmten Datei gehören.
Mp3tag ist dazu geeignet, solche Daten zu erfassen, zu speichern und zu zeigen.

Es ist klar, dass auf diese Art und Weise bestimmte Daten mehrfach vorhanden sind, also jede getaggte Musikdatei ein Päckchen mit weitgehend denselben Daten mitschleppt, wie sie gleichzeitig auch in den anderen Musikdateien in der zusammengehörigen Sammlung vorhanden sind.
So wird sich bei den Musikdateien einer CD in jedem Tag-Bereich die komplette Beschreibung der dazugehörigen CD befinden.

Man kann jeder Datei einer CD die gesamten Daten der zugehörigen CD in einem Tag-Feld mitgeben.
Somit wäre jede einzelne Musikdatei immer mit einem kompletten Tag ausgestattet, ...
was für die Zusammenarbeit mit Mp3tag ideal ist.

DD.20170627.1715.CEST

Genau so bzw. so ähnlich. Wie genau ich was machen will weiß ich noch nicht - ich suche noch sinnvolle Wege. Ziel ist es, wie hier beschrieben: Möglichst schnell ein bestimmtes Lied finden und abspielen.

Dazu wollte ich einmalig bzw. vor einer Party alle Tags mit MP3TAG als csv exportieren und (in Access) einlesen bzw. verknüpfen. Wenn sich Teile der Tabelle dann noch einfach ausgliedern lassen über Tabellenerstellungsabfragen usw. um so schöner. Aber inzwischen habe ich gesehen, dass ich außer dem CD-Titel kaum Daten habe, die nicht Lied-spezifisch sind, so dass ich nur 1 Spalte "zu viel" habe. Damit könnte ich notfalls leben.

In den Spalten? Pro Lied eine Tabellenzeile doch wohl eher, oder?

Wir diskutieren hier wirklich eine Zeitdauer?
Du treibst gerade einen unbändigen Aufwand, eigentlich schon vorhandene Informationen in ein anderes Medium zu überführen. Ich schließe mich da DetlevD an, der fragt, ob sich der Aufwand auch wirklich lohnt.

Ebenso sind die Funktionen zum FInden in so gut wie jedem Abspieler schon vorhanden, so dass sich der Access-Weg eigentlich nur lohnt, wenn das auch eine dauerhafte Lösung wird und alle Bearbeitungen im Leben einer Audiodatei stand hält:
Einfügen, ändern, löschen.
Ich vermute, dass dies nur dann einigermaßen reibungslos funktioniert, wenn beide Systeme (mp3-Datei und Access-Datenbank) einander zuspielen und schon einmal gewonnene Informationen wiederverwenden, so dass man nicht jedes Mal von vorne anfangen muss.
Wenn aber Daten an unterschiedlichen Stellen verändert werden können (mal in der MP3-Datei und mal in der Access-Datenbank) dann muss es regelmäßige Synchronisierungen geben - und die dauern dann.

Ich stimme übrigens nicht mit dir überein, dass es nur den Albumtitel als Daten zum recyclen gibt: je nach Brachialität gibt es auch ALBUMARTIST, ARTIST, YEAR, GENRE.

Aber auch hier: wenn es eine sinnvolle Schnittstelle zwischen Datenbank und Audiodateien geben soll, dann müssten die Datenbank-internen IDs auch in den Audiodateien gespeichert werden, um bei der Aktualisierung die GLeichsetzung mit der Datenbank hinzubekommen.

Aber das ist nur meine Meinung. Du wirst einen Weg finden.

Mit dem Mp3tag Filter kann man eigentlich recht schnell etwas finden, ...
zunächst müssen Dateien in Mp3tag eingeladen sein, ...
dann den Suchbegriff (sinnvolle Zeichen oder Worte) in die Filterzeile eingeben, ...
und Mp3tag zeigt den oder die Treffer an.

DD.20170628.1120.CEST