Bessere Performance beim Hinzufügen umfangreicher Tags, durch Kontrolle über die Größe des Padding Bereichs Options

[u302320]

Wie vielleicht schon aus anderen Postings von mir hervorgeht, bin ich gerade damit beschäftigt, meine mp3's neu mit ID3v2.3 Tags zu versehen. Für jede Datei muss ich eine Daten über eine Websource abrufen und eine umfangreiche Actiongroup ausführen. In beiden Schritten werden eine Reihe von umfangreichen Tags bzw Frames neu hinzugefügt.

Nun scheint es sich so zu verhalten, das mp3tag immer dann, wenn die Menge der zu schreibenden Tags nicht in den dafür reservierten Bereich - bei id3v23 am Anfang der Datei - passt, eine temporäre Kopie mit mehr Platz für die Tags anlegt, sie dort hineinschreibt. Danach wird das Original durch die temporäre Datei ersetzt.

In meinem Fall läuft es darauf hinaus, dass beim Aufrufen der Websource nicht genügt Platz für die vollständigen Daten vorhanden sind, also muss die Datei hier zum ersten Mal vergrößert werden. Dann kommt die Action Group, in der ein oder mehrere Bilder gesetzt werden und auch dort muss wieder die Datei vergrößert werden. Da die Dateien bei mir im Schnitt zwischen 50 und 100MB groß sind, und meine Festplatte langsam bzw. der Kram teilweise auf einem NAS liegt, dauert das Umkopieren und Vergrößern elendig lange.

Daraus ergeben sich für mich folgende Vorschläge:

• Eine Option mit der man die Anfangsgröße des Padding-Bereichs konfigurieren kann. In meinem Fall weiss ich zB, dass ich mit Liedtexten und diversen Images bis zu 250 kb für Tagdaten benötige. Wenn ich die Möglichkeit hätte, irgendwo im Programm zu festzulegen, dass die Padding Area von Anfang an mit 250kb angelegt wird, dann sollte wenigstens das mehrfache Vergrößern und Umkopieren der Datei entfallen.
• Eine Funktion, um die Padding Area auf das notwendige Maß zu schrumpfen. Im Moment scheint Cut&Paste der Tags die einzige Möglichkeit zu sein, wobei auch dann (leider) wieder die Datei zweimal umkopiert wird, also einmal mehr als notwendig, wenn es nur um das Verkleinern des Padding-Bereichs geht.
• Eine Option, mit der festgelegt werden kann, dass Änderungen direkt auf dem Original (also ohne Umweg über temporäre Dateien) vorgenommen werden. Wie gesagt, Option, weil sowas soll ja niemanden aufgezwungen werden.
• die Möglichkeit, mehrere mp3tag-Instanzen starten zu können, sofern nicht technische Gründe dagegen sprechen.

Das diese Ideen nicht völlig ungewöhnlich sind, mag das Beispiel "mp3 diags" zeigen. Dort gibt es die meisten der von mir hier vorgeschlagenen Funktionen in der einen oder anderen Form.

-u302320

[DetlevD]

... In meinem Fall läuft es darauf hinaus, dass beim Aufrufen der Websource nicht genügt Platz für die vollständigen Daten vorhanden sind, also muss die Datei hier zum ersten Mal vergrößert werden. Dann kommt die Action Group, in der ein oder mehrere Bilder gesetzt werden und auch dort muss wieder die Datei vergrößert werden. Da die Dateien bei mir im Schnitt zwischen 50 und 100MB groß sind, und meine Festplatte langsam bzw. der Kram teilweise auf einem NAS liegt, dauert das Umkopieren und Vergrößern elendig lange. ...

'u302320', deine Vorschläge sind gut begründet und sollten auch nicht unberücksichtigt bleiben.

In der Zwischenzeit könntest du dir damit behelfen, einmalig in einem Vorlauf ein Tag-Feld anzulegen und mit einer gewissen Menge Zeichen zu füllen, so dass damit das erforderliche Padding vorbereitet ist (z. B. Tag-Feld 'COMMENT' oder 'UNSYNCEDLYRICS' oder ein selbst definiertes Tag-Feld benutzen, das keine besondere Längenbeschränkung kennt, mit Aktion 'Tag-Feld formatieren' und mit Funktion $repeat() füllen).
Ein großes Dummy Cover Bild sollte auch schon reichen.
Am Ende der späteren Tag-Bearbeitung, löschst du dann dieses temporäre Tag-Feld.
Vielleicht spart man damit das mehrfache Erweitern des Tag Bereichs.

DD.20110428.1303.CEST

This post has been edited by DetlevD: Apr 28 2011, 12:01

[u302320]

Hallo Detlef,

danke für deine Rückmeldung.

In der Zwischenzeit könntest du dir damit behelfen, einmalig in einem Vorlauf ein Tag-Feld anzulegen und mit einer gewissen Menge Zeichen zu füllen, so dass damit das erforderliche Padding vorbereitet ist (z. B. Tag-Feld 'COMMENT' oder 'UNSYNCEDLYRICS' oder ein selbst definiertes Tag-Feld benutzen, das keine besondere Längenbeschränkung kennt, mit Aktion 'Tag-Feld formatieren' und mit Funktion $repeat() füllen).
Ein großes Dummy Cover Bild sollte auch schon reichen.
Am Ende der späteren Tag-Bearbeitung, löschst du dann dieses temporäre Tag-Feld.
Vielleicht spart man damit das mehrfache Erweitern des Tag Bereichs.

Gute Idee, klappt aber leider nicht. Scheinbar reserviert mp3tag nur einen sehr kleinen Bereich für zusätzliche Tagdaten bzw. reduziert die Dateigröße sehr schnell, sobald nur wenige kb frei geworden sind.

Den Ansatz mit den Covern konnte ich nicht ausprobieren, obwohl ich ihn eigentlich recht elegant fand. (Da mp3tag darauf besteht mich per Popup zu fragen ob ich bestehende Cover ersetzen, will fallen Cover in websource skripts weg.Keine zusätzlichen Klicks. Analoge Probleme gibt es bei Dummy Covern in Aktionen.)

Ich habe also den Weg über "Import Text File" genommen und die Tagdaten entsprechend aufgebläht. Um den so belegten Platz für meine eigentlichen Daten zu nutzen, muss ich dieses Dummy-Tag freigeben oder auf einen Wert setzen, der nur ein paar Bytes braucht.
Und da liegt genau das Problem - sobald ich das tue, verkleinert mp3tag sofort die Dateigröße und ich bin wieder an meinem Ausgangspunkt - zuviele Daten für einen zu kleine padding area, deswegen umkopieren, deswegen lange warten. Das deckt sich auch mit meiner Beobachtung, dass jede "import cover" Aktion zum umkopieren der Datei zu führen scheint.

Schade, wäre eine feine Lösung gewesen.
-u302320

Nachtrag:
Weitere Experimente bringen mich zur Ansicht, das mp3tag ziemlich genau 4.5kB für Tagdaten reserviert. Das ist natürlich für jedes Bild, längere Lyrics etc. deutlich zu wenig, wenigstens in meinem Fall. In den seltenen Fällen, in denen ich weniger als 4,5kb Tagdaten einfüge, geht es blitzschnell.

This post has been edited by u302320: Apr 28 2011, 13:39

[DetlevD]

... Gute Idee, klappt aber leider nicht. ... Schade, wäre eine feine Lösung gewesen. ...

Hmm, nächste Idee ...
Belasse die Originaldateien so wie sind und lege von jeder Originaldatei eine leere Kopie an, also ohne Musikdaten, nur den Tag, und der Tag braucht am Anfang auch nicht vorhanden zu sein, also der Dateiname reicht aus. Für die Arbeit mit 'WebSource' sind aber ein paar Tag-Feld Daten notwendig, oder?
Bei MP3 kann man mit einer 0 Byte Datei, vielleicht besser mit einer 1 Byte Datei beginnen.
Andere Dateitypen habe ich noch nicht ausprobiert.

Alle Tag-Arbeiten werden auf diesen Dummy Dateien ausgeführt.
Schließlich werden die in den Dummies gespeicherten Tag-Daten via Mp3tag Clipboard von den Dummies auf die Originale kopiert ("gestempelt").

Jetzt kommt die Frage, wie man einen existierenden Ordnerbaum mit allen Dateien so kopiert, dass man einen 'gespiegelten' Ordnerbaum nur mit 1 Byte großen Dummy Dateien erhält.

Siehe dort ...
http://forums.mp3tag.de/index.php?showtopi...ost&p=28098

DD.20110428.1535.CEST

This post has been edited by DetlevD: Apr 28 2011, 14:33

[u302320]

Hmm, nächste Idee ...

Vielen Dank für deine Mühe!

Leider vereinheitliche ich auch die Dateinamen während der Ausführung der Action group, weswegen dein Vorschlag für meine konkrete Situation wohl nicht ganz passt, da ich diese Namens-Änderungen tracken und dann irgendwie auf den Originaldateien nachvollziehen müsste. Obwohl.... vielleicht könnte man das Umbenennen in beiden Bäumen gleichzeitig vornehmen. Hmmm, muss ich nochmal überdenken.

-u302320

[DetlevD]

... Leider vereinheitliche ich auch die Dateinamen während der Ausführung der Action group, weswegen dein Vorschlag für meine konkrete Situation wohl nicht ganz passt, da ich diese Namens-Änderungen tracken und dann irgendwie auf den Originaldateien nachvollziehen müsste. Obwohl.... vielleicht könnte man das Umbenennen in beiden Bäumen gleichzeitig vornehmen. Hmmm, muss ich nochmal überdenken. ...

Beim Kopieren von Tags ("Stempeln") via Clipboard verlässt sich Mp3tag nur auf die in der Listenansicht gegebene Reihenfolge der Dateien (Dateinamen werden nicht beachtet).

Das Umbenennen und möglicherweise das Verschieben der Dateien kann mit den fertig getaggten 'Vollversionen' in der abschließenden Phase real geschehen, oder ...
... bei den Dummy Dateien 'virtuell' geschehen in einem dafür vorgesehenen Tag-Feld, dessen Inhalt (der neue Dateipfadname) dann später für die Umbenennung nur ausgelesen und angewendet werden muss.

DD.20110428.1606.CEST

This post has been edited by DetlevD: Apr 28 2011, 15:04

[pone]

Du könntest auch die Namensänderung nur in einem extra angelegten Feld der dummy mp3 vollziehen und diese erst am Schluss auf die original Datei in den Dateinamen übertragen.