APEv2 - Cover Art (Front) - [TODO: deal with binary]

Habe seit gestern einiges versucht ... das ist meine Erfahrung = Feststellung (bei soviel try and error könnte ich aber auch was durcheinander gebracht haben ;-). Ich hoffe du kannst das so bestätigen ?!

Ich hoffte auf eine Funktion wie $meta(), die generisch einzelne Felder (die mp3tag nicht schon kennt, wie mein Liebling "Cover Art (Front)" ) eines Tags auslesen könnte ! mp3tag kann ja auch mit benutzerdefinierten Felder in Tags umgehen ... (ev. bring ich auch nach dem vielen Rumprobieren was durcheinander :wink:

Hmm, nein.

Die Funktion $meta zeigt eine Liste von Textwerten an, die jeweils mit demselben Tagnamen angelegt sind.
Das hat aber keinen Bezug zu diesem Zusammenhang hier.

Meines Wissens zeigt Mp3tag alles an, was es erkennen kann, und was es anzeigen möchte.

Siehe auch ...
Export or backup all tag fields

... und ...
http://forums.mp3tag.de/index.php?act=atta...ost&id=5497

Download/copy/move this MTE file ... into the folder ...

(Win XP) %APPDATA%\Mp3tag\Export
resp. (newer OS) %APPDATA%\Roaming\Mp3tag\Export<!--sizec-->

Mit diesem Export Skript kannst du eine komplette Inhaltsübersicht erzeugen.

DD.20140413.1207.CEST

THX, der 2. Link funkt nicht ?!
Könnte man aus dem was machen: Beschränke ich auf ID3 heist das cover = Other, Bei APE = Front Cover, Cover Art (Front).jpg Wie krieg ich diese Infos, die in der Übersicht neben beim Bild angezeigt werden, in eine Spalte ?

Könnte man einen TMP-Tag erzeugen der nicht in den Files geschrieben wird, den man zuerst mit der Einstellung "nur ID3 lesen" als Aktion1 mit %tmp% = %_covers% befüllt und dann bei Einstellung "nur APE lesen" Als Aktion2 %tmp%=%tmp%+%_covers% ergänzt

Probiere nochmal, es müsste eine Download Bestätigung angezeigt werden.

Ja, man kann die Inhalte aus dem einen Tagtyp lesen und in den anderen Tagtyp schreiben bzw. kopieren.
Dabei sollte man die Ziel-Tagnamen dann so wählen, dass im Ziel-Tagtyp bestehende Tagfelder nicht verändert werden.

Beispiel
ID3v1 lesen
ID3v2 schreiben
Aktion "Tag-Feld formatieren"
Feld: ID3V1_TITLE
Formatstring: %TITLE%
... usw. eine Aktion je Tagfeld ...

Beispiel für alle Felder auf einmal
ID3v1 lesen
ID3v2 schreiben
Aktion "Tag-Feld formatieren"
Feld: LIST_ID3V1
Formatstring: $list(,'="','"'$char(13)$char(10))

Beispiel für alle Felder auf einmal
... plus Anzahl Covers
APE lesen
ID3v2 schreiben
Aktion "Tag-Feld formatieren"
Feld: LIST_APE
Formatstring: $list(,'="','"'$char(13)$char(10))'_covers="'%_covers%'"'$char(13)$char(10)

DD.20140413.1950.CEST

!!!!!THX!!!!! Bin gerade am probieren ... so ganz raff ich es noch nicht :wink:

  • Wo ist den die $list funktion dokumentiert ? Gibts noch mehr "hidden secrets" z.B. $loop ?
  • Wo ist die scriptsprache der .mte files beschrieben ?

$list
Lyrics aus Datei importieren?

MTE Skript
$loop/$loopend
Mp3tag Hilfe Manual, Export.
/c/export

Eine allgemein gültige Syntax versuche ich seit vielen Jahren zu entdecken und bin immer wieder überrascht, welche Klimmzüge man machen muss, was in anderen Skriptsprachen nicht notwendig ist.
Eigentlich musst du dir abgucken aus vorhandenen Skripten was nötig ist, was möglich ist, was man durch Tricks möglich machen muss. Hier gilt besonders: Nobody is perfect!

DD.20140415.1147.CEST

THX, kannst du mir bitte erklären wann du ' benutzt ... anscheinend je Variable '%xxxxx%' und für den ganzen Formatstring nochmal ??

"%COVER_ID3_APE% <cov=%_covers% $left(%_tag_read%,1)>$char(13)$char(10)"

oh ein fundamentales Prob hab ich schon noch ... ich dachte wenn ich ein Feld per Aktion erzeuge wird das nicht gleich in den file geschrieben ... wird es aber schon.

Ich möchte aber nichts Schreiben, sondern nur eine temp. Variable, die ich als spalte anzeigen kann.... gibts da ne Lösung ?

In den Mp3tag Skriptsprachen für Export und Formatstrings wird das Zeichen APOSTROPHE ' x27 d39 U+0027 als Anführungszeichen zur Einfassung von Zeichenkonstanten benutzt.

Dabei ist die Syntax ziemlich lose definiert und kann auch vom Anwendungsfall abhängig sein, sodass eine Zeichenkonstante gelegentlich auch ohne Anführungszeichen geschrieben und tatsächlich benutzt werden kann.
Das bedeutet, manchmal muss, manchmal kann eingefasst werden, ...
ich meine, eine Zeichenkonstante sollte immer deutlich erkennbar sein.

Weil ich Texteditoren benutze, die Syntax-Kolorierung anbieten, versteht es sich von selbst, dass man die Mp3tag Skriptsprache einem Standard gemäß anwendet nach eindeutigen Regeln.
Das hilft auch dabei, Schreibfehler sofort zu erkennen.
Außerdem erkennt man leicht den Unterschied zwischen den Sprachobjekten ...

'Zeichenkonstante', %TAG_FELD%, $Funktion

Deshalb benutze ich zur Einfassung von Zeichenkonstanten immer das Apostroph.

DD.20140415.1355.CEST

Du kannst den Ergebniswert von ...
Funktionen wie z. B. $list oder $left(%_tag_read%,1), ...
oder den Wert von Tagfeld-Variablen, wie z. B. %ARTIST%, ...
oder den Wert von Info-Variablen, wie z. B. %_tag_read%,
in der Listenansicht anzeigen und dort auch mit Skriptfunktionen bearbeiten (siehe Dialog "Spalten").

Allerdings sieht Mp3tag immer nur einen Tag-Typ, wie es in den Optionen zum Lesen eingestellt ist.
(Prioritätenreihenfolge: APE > ID3v2 > ID3v1)

Wenn man einen Wert aus einem "tiefer liegenden" Tag-Typ in einem "höher-liegenden" Tag-Typ verwenden will, dann muss man den Wert aus dem "tiefer liegenden" Tag-Typ in ein Tag-Feld in dem "höher-liegenden" Tag-Typ kopieren (schreiben).
Kopieren (schreiben) von "oben" nach "unten" sollte auch funktionieren.

DD.20140415.1500.CEST

THX, OK mein Fehler war also meine HilfsVariable %COVER_ID3_APE% per Aktion in 2 Schritten zu erzeugen .... bei Aktionen wird immer geschrieben ...

tiefer höher versteh ich prinzipiell ... aber wie hast du das kopieren (ohne zu schreiben) gemeint

sinngemäß so oder so ähnlich :wink: ???

kopieren:
Z.B. 3 Spaltenfelder erzeugen %COVER_APE%, %COVER_ID3%, %COVER_ID3_APE%

wenn Ape               $if($leql(%_tag_read%,"APEv2", 
dann                       %COVER_APE%=%_cover%
sonst wenn ID3             $if($leql(%_tag_read%,"ID3v2", 
dann                          %COVER_ID3%=%_cover%

Dann noch:             %COVER_ID3_APE%=%COVER_APE% + %COVER_ID3%

Nun könnte ich nach %COVER_ID3_APE% sortieren ....

ID3v2 schreiben ID3v2 lesen COVER_COUNT_ID3 <== $ifgreater($strstr(%_tag_read%,'ID3v2'),0,%_covers%,) Hinweis: 0 covers ... kein Tagfeld ID3v2 schreiben APEv2 lesen COVER_COUNT_APE <== $ifgreater($strstr(%_tag_read%,'APEv2'),0,%_covers%,) Hinweis: 0 covers ... kein Tagfeld ... oder ... ID3v2 schreiben ID3v2 lesen COVER_COUNT_ID3 <== $ifgreater($strstr(%_tag_read%,'ID3v2'),0,%_covers%,0) Hinweis: 0 covers ... ein Tagfeld mit '0' ID3v2 schreiben APEv2 lesen COVER_COUNT_APE <== $ifgreater($strstr(%_tag_read%,'APEv2'),0,%_covers%,0) Hinweis: 0 covers ... ein Tagfeld mit '0' Spaltenwert oder Tagfeld ID3v2 lesen COVER_COUNT_ALL <== $add(%COVER_COUNT_ID3%,%COVER_COUNT_APE%)

Vielleicht gibt es einen anderen Weg zur Lösung der Frage, wieviele Bilder sind in welchem Tag-Typ gespeichert, und was hat das für Folgen?

  1. Aus jedem Tag-Typ exportierst du alle Bilder in einen Ordner.
    Dabei kannst du für den jeweiligen Tag-Typ in den Bildnamen ein Merkmal einbauen.
    (Aktion "Album-Cover exportieren")
    So erhältst du alle Bilddateien in einem Ordner.
  2. Dann kannst du alle Bilder aus den Tag-Typen entfernen.
  3. Dann importierst du welches Bild auch immer in welchen Tag-Typ auch immer.
    (Aktion "Album-Cover aus Datei importieren")

Das mit den "doppelten Bildern" muss nicht sein, denn wenn die Bilder in beiden Tag-Typen dieselbe Qualität haben, dann kann man beim Exportieren denselben Bildnamen verwenden und ein bereits vorhandenes Bild würde überschrieben werden (... musst du ausprobieren).

DD.20140415.1640.CEST

COVER_COUNT_ID3: $ifgreater($strstr(%_tag_read%,'ID3v2'),0,%_covers%,%COVER_COUNT_ID3%)
hätte das jetzt so versucht, aber es wird je nach Einstellung immer nur eine der 2 Spalten angezeigt.

Und die add Spalte ist immer 0 ...

Ich kann überhaupt keine der 2 Hilfsspaltenvariablen in einer 3 Spalte anzeigen:
COVER_COUNT_ALL <== %COVER_COUNT_ID3%
zeigt unabhängig von der Einstellung ID3/APE nie was an

Ich weiß jetzt nicht ob ich etwas falsch verstanden habe ... du musst bedenken, ... du kannst nur dann covers zählen, 'wenn du dich in dem Tag-Typ befindest, in dem diese covers gespeichert sind'.

  1. APEv2 lesen und dort cover zählen, das Ergebnis in ein Tagfeld nach ID3v2 schreiben.
  2. ID3v2 lesen und dort cover zählen, das Ergebnis in ein Tagfeld nach ID3v2 schreiben.
  3. Beide Tagfelder sollten nun im ID3v2 zu sehen sein und die Inhalte können in Spalten angezeigt und weiter ausgewertet werden.

DD.20140415.1616.CEST

ev. verstehe ich es auch falsch "nach ID3v2 schreiben" ...
Damit meinst nur die Einstellung, in die Files wird nichts geschrieben ... solange ich keine Aktion ausführe (hoffe ich)

Ich habe 3 benutzerdefinierte Spalten angelegt ....

Wenn ich nur APE lesen (und ID3 schreiben) einstelle zeigt nur Spalte COVER_APE eine 1, COVER_ID3 zeigt nichts und die Summenspalte =0

Wenn ich dann nur ID3 lesen (und ID3 schreiben) einstelle zeigt nur Spalte COVER_ID3 eine 1, COVER_APE zeigt nichts und die Summenspalte =0

Nach meinen Versuchen, würde ich sagen, dass man keine benutzerdefininerte Spalten in einer weiteren benutzerdefinierten Spalten nutzen kann, außer man schreibt die Spalten per Aktion in die Files ?!

Das wäre sehr sehr schade :frowning:

Du kommst nicht umhin, mindestens ein Tag-Feld anzulegen/zu schreiben, ... in welchem Tag-Typ (ob ID3v2 oder APEv2) ist eigentlich egal, jedenfalls muss es der Tag-Typ sein, in dem das Tag-Feld dann ausgewertet werden kann.

Angenommen du willst die beiden Werte im Tag-Typ ID3v2 verfügbar haben, dann ...

  1. ... in Optionen einstellen ... ID3v2 schreiben, APEv2 lesen
    Tagfeld formatieren mit dem Wert von %_covers%
    COVER_COUNT_APE <== %_covers%

  2. ... in Optionen einstellen ... ID3v2 schreiben, ID3v2 lesen
    Tagfeld formatieren mit dem Wert von %_covers%
    COVER_COUNT_ID3 <== %_covers%

Du musst in den Optionen den Tag-Typ einstellen, den du lesen willst, dann die einzelne Datei mit [Strg+T] auslesen oder mit [F5] die Anzeige aktualisieren für alle Dateien.

DD.20140415.1703.CEST

Wenn du für Kalkulationen usw. eine dauerhafte 'temporäre Variable' benötigst, dann kommst du nicht umhin in jeder zu bearbeitenden Datei ein Hilfsfeld anzulegen, was dann später wieder entfernt werden kann.
Besonders betrifft das dein Vorhaben, was Inhalte in zwei Tag-Typen vergleicht.
Wenn du aus irgendeinem Grund temporäre Tagfelder nicht anlegen magst, dann gibt es noch den Weg über den Export, um damit die notwendigen Daten sichtbar zu machen.

Wie meinst du das genau mit den 'benutzerdefinierten Spalten'?

Im Dialog "Spalten" kann man im Feld "Wert" ...
sowohl die Werte von Tagfeldern direkt benutzen, z. B. %ARTIST%, ...
wie auch einen Mp3tag Skriptausdruck verwenden, z. B. $ifgreater(%_covers%,0,'JA','NEIN').

DD.20140415.1718.CEST

THX, hatte ich befürchtet ... Da die von mir erzeugten Hilfsspalten "COVER_ID3 und APE" ja nicht ins File geschrieben werden, zeigt vermutlich die Hilfsspalte mit der Summe $add(%COVER_ID3%, %COVER_APE%) immer 0...

$getenv(x) ... ein PUT/SET dazu gibt's ja nicht oder ?

$put(x,y) ... da steht geht nur bei Export, könnte man das "zweckentfremden" ?

Ja, das ist doch verständlich, wenn eine %VARIABLE%, leer ist bzw. nicht existiert, dann behandelt Mp3tag den nicht vorhandenen Inhalt bei Berechnungen als 0 oder bei Stringmanipulationen als leere Zeichenkette.

Die Funktionen $put, $puts, $get wirken nur beim Export.
Auch mit einem Exportskript wirst du die Prioritätenreihenfolge der Tagtypen nicht umgehen können.

Warum sträubst du dich gegen das Anlegen von temporären Hilfstagfeldern?

DD.20140416.1125.CEST