Liebes Forum,
bei der Normalisierung per Massenbearbeitung erscheint bei mir ein Fehler beim Abspeichern – leider erst dann, denn die ganze Normalisierungsarbeit ist dann für die Katz.
[FireDAC][Phys][MySQL] Unknown column 'INF' in 'field list'.
Ein Bugreport steht zur Verfügung.
Unbekannte Grüße
TSD
Ich weiß, daß pushen hier völlig unnötig ist, und ich weiß auch ob des Boß’ Auslastung, aber könnte es hierzu möglicherweise mal eine Stimme geben?
Sorry, der ist mir am Freitag Nachmittag durchgerutscht, und zwei Tage später lag ich in der Notaufnahme.
Ich bemühe mich um Aufarbeitung und bitte um Entschuldigung.
Wenn es morgen meine Zeit erlaubt, versuche ich das nachzustellen.
Langsam, für den Notfall kannste nix! Es sollte nur nicht vergessen gehen.
Ist mir jetzt schon mehrfach untergekommen; offenbar liefert der R128-Scanner (ebur128.dll) vereinzelt eine Lautheit von “minus unendlich” zurück, die dann als Wert nicht in das vorgesehene Feld in der Datenbank “passt”.
Meinst du, du kannst das vorsichtig auf die betroffene(n) Datei(en) eingrenzen und mir eine solche zum Test zur Verfügung stellen?
Ich suche mal. Blöd ist halt, daß dann der ganze Schwung der Massenbearbeitung hinfällig ist anstatt nur die maliziöse(n) Datei(en).
Ok, also bräuchten wir da mal so ein Abort/Retry/Cancel-Dialog?
Edit: Nehme den Vorschlag zurück. Funktioniert nicht, da alle Updates innerhalb einer SQL-Transaktion stattfinden.
So, einen Kandidaten habe ich gefunden (und hochgeladen). Ich gebe zu, daß die Datei ein wenig exotisch ist, aber wiederum doch nicht so, daß sie irgendwo anders nicht auch vorkommen könnte. Es handelt sich um ein Prüfsignal mit dem durchgängigen Pegel „digital Null“, was natürlich so einen Normalisator an seine Grenzen bringen kann. Die Ausgabe im Schaufenster lautet für dieses Audio
W:\Musik\Media.localized\hr\Meß- und Prüfsignale\99 Titel 99.aif: 998,0 dB
Wenn man die Normalisierung einzeln (in den Eigenschaften) anstößt, kommt bei der Berechnung des Durchschnittspegels halt -INF heraus. Das ist formal richtig, könnte aber vom Algorithmus auch anders gehandhabt werden. (Oder eben von mAirList abgefangen.)
Die andere Baustelle wäre halt die SQL-Transaktion. Auch hier müßte solch ein Fehler eigentlich abgefangen werden können. (Oder Du läßt auch alphanumerische Zeichen im betreffenden Feld zu.)
Entdeckte Grüße
TSD
Hier ist noch ein Kandidat, allerdings aus einem, na ja, „normalen“ Umfeld, und auch nicht so radikal:
W:\Musik\Media.localized\Beatles\…\49-26 Silence.mp3: 62,6 dB
Trotzdem reicht’s um ein -INF hervorzurufen. Upload ist unterwegs.
Ähm, sehe ich das korrekt, dass diese Datei nur aus Stille besteht (wie der Titel schon sagt)? Das würde “minus unendlich” als Lautheit durchaus rechtfertigen.
Und wo kommen diese 62,6 dB her? Das hat jetzt nichts mit R128 zu tun, oder?
Die machen Dein R128-Normalisator; sie wurden bei der Massenbearbeitung im Hab-ich-schon-alles-geschafft-Fenster bei der Normalisierung durch Massenbearbeitung angezeigt:
Bei der Einzelvermuggelung über Eigenschaften > Audio-Datei sieht es so aus:
Sag ich ja (siehe oben). Aber mAirList sollte das abfangen können. Der Wert als solcher ist ja erstmal nicht schädlich, nur, daß er eben alphanumerisch ausgegeben wird.
Edit: Meine Editiererei und Torbens Beitrag haben sich überschnitten, daher das doppelte Bild. Ist aber gut, wenn beide zum selben Ergebnis kommen.
Ach so, als Verstärkung. Ja, es ist scheinbar tatsächlich so, dass die ebur128.dll für Nullsamples den Pegel (Peak) -63,6 dBFS zurückliefert:
“Minus unendlich” ist eigentlich innerhalb einer Programmiersprache schlecht darstellbar. Daher wundert es mich nicht, dass die DLL dafür dann ersatzweise einen “sehr niedrigen” dB-Wert einsetzt. Ich selbst verwende für den Zweck den Wert -200 dB.
Diese INF-Werte waren mir ehrlich gesagt bisher gar nicht bekannt.
Hier steht ein Hinweis darauf, warum libebur128 in diesem Fall “minus unendlich” zurückliefert: Signals shorter than 0.5 seconds return -inf using global loudness function · Issue #106 · jiixyj/libebur128 · GitHub
Der R128-Standard verlangt für eine korrekte Messung, dass das Signal mindestens 500ms lang über einem Pegel von -70 LUFS liegt. Das ist bei einer Stille-Datei natürlich nie der Fall. Damit ist der Pegel definiert als “minus unendlich”. Alles korrekt soweit.
Das macht bei uns aber ziemlich viel kaputt. Unter anderem das Abspeichern in der Datenbank. Oder auch die Normalisierung (die ja die Differenz aus Zielpegel und gemessenen Pegel als Verstärkung nimmt).
Also was tun? Einen sinnvollen Ersatzwert eintragen? Welchen?
Die Datei einfach von der Normalisierung ausnehmen? Ist ja streng genommen auch sinnlos. Also etwa
if Durchschnittspegel = '-INF' then
SkipNormalization;
Noch eine seltsame Datei gefunden. Hat eine Größe von 692 KB, läßt sich aber aus irgendeinem Grunde nicht abspielen und erscheint also mit Pegel Null. Andere Titel des Albums sind unverdächtig.
Es kommt also nicht nur bei Dateien vor, die per se Stille enthalten, sondern auch bei welchen, die aus irgendeinem Grunde defekt sind, was bei einem größeren Archiv ja immer mal vorkommen kann.
Zwei Audios hochgeladen. Take 12 ist der mißliche, Take 11 aus demselben Album problemlos.
Gerade Build 4412 hochgeladen. Bei solchen Dateien ohne gültige R128-Lautheit (zu leise, zu kurz) bleibt das entsprechende Feld nach dem Scannen nun einfach leer.
Großartig, funktioniert! Danke!!