Datenbanken habe ich genug, keine die so vielfältig ist. MP3db, damit habe ich angefangen, ist aus 2012, wird nicht mehr gepflegt, zeigt aber die Bitrate an 
BPM Studio und Radio Boss. Ich kann zwar die DBs aus den Programmen exportieren, auch als .csv aber habe Probleme die zu importieren in mAirList, das funktioniert irgendwie nicht. Als Notlösung kann das auch nur dienen, ich müsste ja immer wenn ich neue Musik bekomme, das alles erstmal in eine andere DB einlesen, exportieren und dann in mAirList importieren. Umständlich ist das.
Mir will das nicht in den Kopf, aus den TAGs wird, z. B. der Interpret, gelesen aber die Bitrate ist nicht möglich auszulesen??? Die steht doch auch in den TAGs
Man könnte ja mal versuchen, die Bitrate loggen zu lassen.
Das ist unbestritten. Aber kannst du auch belegen, dass das wirklich ID3-Tag-Einträge sind und nicht Dateiinformationen aus der Datei selbst?
An dieser Stelle sollten wir das erstmal auftrennen.
@Conan
Bitte lade zwei Dateien, in denen die Bitrate nachweislich gemäß der Konvention im ID3-Tag steht, via Nextcloud hoch. Ich schaue mir die Dateien dann mal an.
Darum geht es doch gar nicht. Ich dummer Anwender muss doch nichts belegen. Mir ist egal, woher die Information stammt. Es gibt die Information und ich bin Anwender und denke mir: warum kann mein geliebtes mAirList etwas nicht, was mp3Tag kann? Versuche, es mal so zu sehen.
1 Like
2 Dateien sind auf dem Weg
Danke dafür.
Es bleibt dabei: Wir unterscheiden zwischen den Dateiinformationen an sich und den ID-Tags.
Um das mal beispielhaft zu untermauern:
Wenn du dir unter Windows die Eigenschaften der Audio-Datei aufrufst, dann findest du dort zwei Tabs, die sich elementar unterscheiden:
- Audio Properties
und - ID-Tag
So wirst du im Bereich “Audio Properties” Informationen sehen, die noch nie automatisch Eingang in die Attributliste eines Elements von mAirList gefunden haben (Auszug):
Size 4,72 MB (91% Compressed)
Original Size 52,08 MB
Length 5 minutes 9 seconds
Channels 2 (stereo)
Sample Rate 44,1 kHz;
Bit Rate 128 kbps
Encoder FHG (Guess)
Encoder Settings Constant Bit Rate 128 kbps
Audio Quality Low (Lossy)
Contains Album Art, CD TOC, ReplayGain, ID Tag [APEv2 & ID3v2.3 & ID3v1.1]
Channel Mapping Left, Right
Einige der Informationen finden sich auch im Tab “ID-Tag” - aber eben nicht alle. Das hier ist ein anschauliches Beispiel (Channels, Sample Rate, Encoder, Audio Quality etc.).
Sogar die Länge ist dort anders codiert, um den Anforderungen zu entsprechen:
Length 420266
Ich hoffe, damit ist klar, was der Unterschied zwischen Dateiinformationen und Attributen (ID-Tag) ist.
Zur Aussage, dass solche Werte ja auch in Mp3tag stehen würden: Ja, nur die Quelle ist eine andere. Sie stehen nicht im ID-Tag, auch nicht in der erweiterten Ansicht.
Genau das aber war meine Frage.
Was du in den Spalten von Mp3tag siehst, ist eine Definitionsfrage (streng genommen kann da alles stehen, wie eben auch im ID-Tag, nur entspricht es irgendwann nicht mehr der Spezifikation).
Apropos Spezifikation:
Das ist jetzt so was spezielles, da muss Torben ran. Ich habe ihn mal gefragt, ob alle Informationen aus dem ID-Tag in den Bereich “Andere Attribute” übernommen werden können. Irgendwo im Hinterkopf geistert noch 'rum, dass das beim ID-Tag nicht immer (oder nur mit Aufwand) möglich sei, während Vorbis Comment (also *.flac oder *.ogg) da hingegen unproblematisch sei.
Die genaue technische Begründung dafür muss ich mir noch mal besorgen.
Zurück zu Mp3tag: Eigentlich ist auch dort der Unterschied bestens beschrieben. Es gibt an der Stelle nämlich “Tag and Metadata Information” einerseits und “Technical Information” andererseits.
Es gibt noch weitere Abschnitte jenseits der Tag and Metadata Information, aber das würde an der Stelle zu weit führen.
Tag and Metadata Information
You can reference any supported field which is, e.g., listed in the extended tags dialog as
FIELDNAMEvia a placeholder%fieldname%.
So weit, so gut.
Die Bitrate gehört in den Bereich Technical Information:
Technical Information
Technical information fields begin with an underscore
%_and are read-only.
Placeholder Description %_bitrate%Bitrate in kbit/s
Soll heißen: Hier werden die Dateiinformationen (!) ausgelesen, können aber nicht verändert oder zurückgeschrieben werden. Mit %_codec% z.B. ist es ja nicht anders.
Nochmals: Das sind keine Attribute im Sinne des Dateiimports. 
Quelle für die Zitate: Format Strings and Placeholders – Mp3tag Documentation
Zufalls(be)fund:
Da ich nicht mit mp3-Dateien arbeite, bin ich da möglicherweise nicht ganz up to date. Mir ist bei deinen Dateien jedoch etwas aufgefallen, das ich so nicht kenne.
Ich habe mir die Datei-Eigenschaften in Windows aufgerufen und im Tab “ID-Tag” ist mir diese Sektion aufgefallen:
Klar, kenne ich, kein Problem.
Aber in Mp3tag werden sie in den erweiterten Tags nicht angezeigt und dementsprechend auch nicht in mAirList übernommen (bitte beachte den -Hinweis im vorigen Abschnitt).
Das wundert mich, denn das kenne ich anders. Die MP3GAIN_[...]- und REPLAYGAIN_[...]-Tags sollten jedenfalls problemlos in Mp3tag dargestellt werden können.
Warum das hier so ist, kann ich nicht beurteilen. Aber du kannst dem ja mal an anderer Stelle nachgehen; hier nur als Servicehinweis am Rande.
2 Likes
Uli, erstmal schönen Dank für die detaillierten Infos und für die Zeit die du dir dafür genommen hast.
Jetzt weiß ich wo die Informationen stehen aber leider immer noch nicht warum man das nicht in der DB darstellen kann. Offensichtlich funktioniert es doch wenn ich die MP3 über eine .csv importiere, calypso60 hat es so gemacht.
Die Eigenschaften von der Datei, die du aufrufst, sehen bei dir doch etwas anders aus als bei mir (Win 11) wahrscheinlich hast du ein spezielles Programm dafür.
Ich möchte mich nochmal auf calypso60 beziehen, wir Anwender wissen nicht von der Problematik irgendetwas irgendwo darstellen zu können, wir sehen nur dass es in vielen Datenbanken (nicht nur spezielle TAGs Bearbeitungsprogramme) möglich ist und fragen uns: warum hier nicht?
Dazu kommt noch die Frage: warum immer noch nicht? Natürlich habe ich, bevor ich geschrieben habe, alles zu dem Thema gelesen was ich hier gefunden habe. Das Ganze geht doch schon seit 2014. Es wurde zwar immer mal erwähnt, steht auf dem Zettel - momentan keine Zeit aber 9 Jahre keine Zeit?
Grüße durch Raum und Zeit, Holger
10 Jahre
Zugegeben, ist das ein Aufwand der vermutlich nicht mal so nebenbei geschieht für Torben.
Denn für diese Daten muss er den Datei HEADER auslesen und das für alle erdenklichen Audiodatei Typen. Also bleibt es nicht nur bei Mp3.
Ich hatte mal versucht mittels mp3Tag diese Daten als ID3 Meta Tag zu konvertieren. Leider ohne Erfolg.
Mach in mp3tag Mal einen Rechtsklick auf die Spalten. Dann erscheint ein Kontextmenü in der du die nicht angezeigten Tag Felder auswählen kannst. Funfact: Da erscheint dann auch das Feld [MAIRLIST] insofern man diese Daten aus der DB in die Tags der Lieder exportiert hat.
Btw… Solch ein Kontextmenü aus einer Bibliothekspalte aufrufen zu können ist auch nichts neues. Aber das kann ja mAirList auch nicht 
So wie ich die Sache sehe, besteht der Unterschied darin, daß entweder ein Tag ausgelesen wird, der irgendwie heißt (z. B. „Jahr“ oder „Bitrate“) und in dem irgendetwas steht (z. B. „1964“ oder „192“ oder eben auch „Schwarzbrot“). Oder mAirlist soll hergehen und selber analysieren, welche Bitrate die Datei eben hat. Im ersten Falle sollte es auf jeden Fall möglich sein, da es sich ja nur um eine Wiedergabe schon vorhandener Daten handelt, wenn man nur den Namen des Feldes weiß. Daher auch meine Frage nach dem Logging: Wenn das Feld da und bespielt ist, dann sollte man die Daten auch wieder rauskriegen.
mAirList soll doch nicht auch noch die Bitrate analysieren, die Daten sind doch schon in der Datei hinterlegt. Es geht nur um das Anzeigen 
1 Like
[privat]
Hm. Ich hätte jetzt vermutet, mit der Aktion des Transfers des Inhalts von %_bitrate (Technical Information) nach %Bitrate (individuelle Tag and Metadata Information) wäre das möglich.
Muss ich mal in Ruhe testen.
Spoiler: Nicht vorhandene Einträge können auch nicht in Spalten angezeigt werden, selbst wenn man sie extra dafür anlegt. Ich hatte vorab bereits beschrieben, dass in der Anzeige der erweiterten (!) Tag-Anzeige kein Eintrag zu sehen war.
Leer bleibt eben leer. 
Mich hat die Frage beschäftigt, wie mp3s in die Bibliothek importiert werden. Ich habe ja nun mal mehrheitlich flac-Dateien.
Typischerweise sehen die Attribute meiner flac-Dateien so aus:
Nach der Umwandlung in mp3 und Import in die Datenbank war ich ein wenig überrascht:
Am Konvertierungsvorgang liegt’s nicht, da ist gemäß Mp3tag nichts verloren gegangen:
(flac)
(mp3)
Das dürfte die These bestätigen, dass bei mp3-Dateien nur eine gewisse Auswahl an Feldern in mAirList importiert wird.
Meine private Meinung zum Wert der Anzeige der Bitrate einer Audiodatei in einer Radioautomations-Software dürfte in etwa deckungsgleich mit der Frage von Torben vor fast genau vier Jahren sein:
[/privat]
Hallo @TomJumbo83 
Testaufbau:
Testergebnis (mAirListDB, flac-Datei):
Es bleibt aber dabei, dass das mit mp3-Dateien in mAirList nicht geht, siehe vorab aufgezeigte Einschränkung.
Die Aktion selbst in Mp3tag lässt sich natürlich auch auf mp3-Dateien anwenden; das Feld wird beschrieben, nur eben beim Import nicht ausgelesen.
Bitte bedenkt, dass das Tag-Feld frei definiert ist und keiner Spezifikation entspricht.
Ich hätte es auch &Ozelot% nennen können (Insider! 
).
Wenn die Tags aufjedenfall vorhanden sind, werden sie in MP3 Tag auch angezeigt. Dafür Rechtsklick → Alle /Erweiterte Tags anzeigen da sind alle Tags drin, die in diesem Song hinterlegt sind. (soweit meine Auffassung) 
EDIT: hat sich mit dem Beitrag hier:
… ja schon geklärt
Sry das ich mich erst jetzt melde, ich musste erstmal in Urlaub fahren 
Irgendwie habe ich den Eindruck das die Diskussion hier immer mehr verflacht und sich im Kreis dreht. Ich wollte eigentlich nur wissen: Warum wird mir die Information “Bitrate” 'nicht in der Datenbank angezeigt, ich wollte nicht um die technischen Hintergründe wissen, ich kann nicht programmieren.
Auch verstehe ich die Frage von Torben nicht
Die Gründe warum es eben für den Einen oder Anderen wichtig ist wurden ja schon (fast) alle genannt (aber geflissentlich ignoriert) Vielleicht noch so viel dazu: Weil diese Info in jeder (… ) Datenbank einem praktisch aufgezwungen wird, man muss sie, wenn man sie nicht haben möchte, explizit deaktivieren und ich (oder auch wir Fragesteller) gelernt haben mit dieser Information zu arbeiten, doppelte Dateien zu vergleichen und die schlechtere Kopie eben von der FP zu verbannen.
Fazit (für mich) Die Information steht irgendwo in der Datei (sonst könnten die anderen Programme das ja nicht anzeigen) und es ist mir völlig egal wo sie nun genau steht, ob in den erweiterten TAGs oder den unerweiterten Attributen. Ich möchte, und wie es scheint bin ich keinesfalls allein, das auch gern angezeigt bekommen.
Frischluftreiche Nordseküstengrüße, Holger
Hi, das ist mir seit den 10 Tagen, wo ich auch hier im Forum an Board bin, auch aufgefallen. Nur Gegenfragen und ständige sucherei nach Gründen woran man, das doch besser lassen sollte, weil man macht das seit Jahren so. Ohne niemanden direkt anzuhauchen, finde ich es echt schade um das Forum und das Potenzial der vielen schlauen Köpfe hier.
Du hast sicher dein Nutzen dafür, sonst hättest du ja schließlich nicht danach hier im Forum gefragt. Könnte ja sein, jemand hat sich damit ja auch schonmal beschäftigt / oder so in der Art herumexperimentiert und könnte dir Rat geben. Klar ist nicht immer alles sofort oder generell im Bereich des möglichen oder sonst was, aber ich denke das weiß hier jeder von diesem Forum. Immerhin kostet fragen nichts
In diesem Sinne, zu diesem Thema würde ich auch gerne Lösungen lesen, bin da etwas neugierig, hehe ^^ (Derzeit keine Anwendung für, aber in die Zukunft blicken, kann ich bisher noch nicht hehe)
Das wär’ jetzt mein Beitrag allgemein. Ich will nicht länger im Thread hier zwischenfunken (schließlich ist das weder hilfreich noch passend, hat nur mir gerade den Anlass gegeben).
1 Like
Wie ich gelesen habe bin ich nicht alleine damit.
Natürlich ist das so, ich will ja auch nicht das wenn ich was frage mir sofort und auf der Stelle eine plausible Antwort dargeboten wird aber nach 9 Jahren (oder fast 10 ) sollte doch wenigstens irgendwas an Antworten (oder besser noch: Lösungen) vorliegen?
4 Likes
+1, bin ich voll bei dir!
ich geb dir mal nen Daumen hoch 
1 Like
So, jetzt ist es mal gut hier.
Das kommt offenbar davon, wenn man versucht, Hintergründe zu erläutern und sogar Lösungen aufzuzeigen und sich auf die (nicht immer sachlichen) Argumente der Wünschenden einlässt.
Ob sie eine Mehrheit oder relevante Größe darstellen, sei dahingestellt.
Die letzten Beiträge, speziell von @Conan und @onairmitflo, sind dazu geeignet, einfach nur zu sagen: Der mAirList-Support stellt fest, dass das für mp3-Dateien derzeit nicht möglich ist und für andere Formate nur mit ein wenig Mehrarbeit durch die zuständigen Musikredakteure.
Schade um die Zeit und Arbeit, die da rein gesteckt wurde.
Bislang hat uns kein professioneller Kunde diesbezüglich angesprochen. Sein workflow ist schlicht ergreifend anders. Die Verwaltung des Musikbestandes findet üblicherweise vor, und nicht nach der Synchronisation in der Datenbank statt.
mAirList ist eine Radioautomation und keine Musikverwaltungssoftware.
Es wurde in der Vergangenheit auch schon mal gefragt, ob wir keine Hilfe zur Entfernung von Dubletten einbauen können (der Kern der Bitte scheint ja auch darauf abzuzielen).
Antwort: Nein, bitte benutzt dazu Hilfsprogramme dritter Anbieter. Da gibt es richtig gute Software dafür.
Wir vertreten schon immer den Standpunkt, dass der Datenbestand vor dem Import in die Datenbank sauber gepflegt sein sollte. Ganz gleich, ob es nun die Metadaten oder die Ordnerstruktur betrifft.
Gleiches gilt für Dubletten, sofern unerwünscht, und vieles andere mehr, was die Fantasie so hergibt.
Abschließend:
Alle anderen, freiwilligen, privaten und ehrenamtlichen Diskussionsteilnehmer haben die einfache Möglichkeit zu sagen “Ich steige ab einem bestimmten Zeitpunkt aus der Diskussion aus”.
Als Mitarbeiter der mairlist GmbH muss ich mir die Kommentare und Argumente durchlesen und mir mancherlei Behauptungen, ja, stellenweise gar Angriffe zu Gemüte führen, weil es mein Job ist.
Langfristig führt es aber dazu, dass ich einsilbig antworte:
Nein, wir bieten diese Information nicht an und haben zur Kenntnis genommen, dass einige Kunden diese Information gerne sehen möchten, um damit arbeiten zu können.
Nicht schön, aber möglich und irgendwann auch die Konsequenz aus Threads wie diesen.
Dienst nach Vorschrift, kein weitergehendes Engagement.
Das kann nicht der Sinn eines gegenseitigen Austauschs sein.
Ich denke, dass die wesentlichen Argumente nunmehr vorgebracht wurden, damit Torben eine Entscheidung treffen kann.
Sollte die Diskussion nachfolgend ausarten, werde ich den Thread temporär schließen müssen. Lasst es bitte nicht soweit kommen.
Vielen Dank für euer Verständnis und eure sachliche Mitarbeit.
3 Likes
Ich war noch eine Antwort schuldig und bitte um Verzeihung, dass ich erst jetzt darauf eingehe:
Der in #19 gezeigte Screenshot über die Datei-Eigenschaften (ich nehme an, darauf bezieht sich deine Ausage) stammt von Windows 11.
Es wurden keine speziellen Programme oder anderweitige Hilfsprogramme zur Anzeige dieser Informationen genutzt.