Backtiming mit *.flac-Dateien ungenau

Deutsch / German Allgemein
1

Liebe Community,

vielleicht könnt ihr mir helfen: Wenn ich versuche, meine Sendung punktgenau zu TOTH zu Ende zu fahren, stelle ich fest dass das mitunter drei bis vier Sekunden aus dem Ruder läuft, und zwar nach hinten.

Ähnliche Beobachtungen kann ich auch im laufenden Programm machen, wenn während des Abspielens eines Titels das Sendeloch ohne weiteres Zutun um eine Sekunde schrumpft.

Beispiel: Ich starte meinen letzten Song mit erwarteter Endzeit 19:59:59 und lande real bei 20:00:03.
:face_with_raised_eyebrow:
Fakten: Der größte Teil meines Archivs besteht aus flac-Dateien. Nach meiner Recherche sind flac-Dateien als VBR-codiert zu betrachten.

Bei meiner Reise durchs mAirList-Forum stieß ich immer wieder auf Hinweise vom Typ “vermeide VBR, wenn möglich” - aber bei flac scheint das wohl nicht möglich zu sein.

Nun gut, weitere Hinweise dieser Art habe ich in den letzten sieben Jahren von Torben nicht mehr vernommen.

BASS_STREAM_PRESCAN ist gesetzt und das Datei-Management ist aktiviert.
Rein theoretisch also müsste alles sauber laufen. Tut es im Assist jedoch nicht.

Woran könnte das liegen und was habe ich übersehen?
Wie erreiche ich eine bessere Pünktlichkeit?

EDIT: v7.4 Beta Build 5811, aber ich habe es unter “Allgemein” gestellt, damit das Thema nicht irgendwann ins Archiv wandert. Ist vermutlich nicht speziell auf v7 zurückzuführen; falls doch, dann bitte verschieben.

2

Hast Du irgendwo den Pitch verändert? Ich habe die Beobachtung gemacht, dass mAirList zwar pitched, aber die Prozent weniger oder mehr an Laufzeit nicht widerspiegelt…

3

Nette Idee, aber: Nein, nie.
Als Live-DJ am Pioneer vielleicht, ja, aber im Radio allgemein und in mAirList im speziellen: Nope.

Ich habe gerade in der DB Stichproben gezogen. Eine Spalte für die beiden Werte Pitch (%) und Tempo (%) kennt die Bibliotheksansicht ja nun mal nicht.

Und das müsste sich ja quer durch die gesamte Playlist ziehen…

1 Like
4

Das wäre jetzt meine Frage: Du schreibst, daß die Sendung vier Sekunden zu spät aufhört. Ist das auch im Assisitbetrieb der Fall? Wenn der Schlußtitel pünktlich gestartet wurde (bitte prüfen), dann ergäbe sich bei einm Vierminüter eine Laufzeitverlängerung von 1,7 %. Das ist eine Menge.

Lege mal in Audacity o. ä. den letzten Titel aus Deinem Mitschnitt sowie denselben Titel frisch aus der Datenbank auf zwei Spuren untereinander. Sieht man die Differenz? Falls ja, ist sie ach zu hören?

1 Like
5

Es ist zu früh: Ich kaufe ein E und ein U und habe ein I abzugeben.

1 Like
6

Tritt das Verhalten wirklich nur bei flac-Dateien auf?
Ich hatte ein ähnliches Verhalten auch bei mp3-Dateien. Ohne es - aus Zeitgründen - genauer untersucht zu haben, tritt das Problem bei mir nicht mehr auf, seitdem ich beim Schlusstitel immer den Fade-Out-Cue-Punkt entferne und den Cue-Out-Punkt, wenn möglich, etwas nach hinten verlagere! Bei Gelegenheit werde ich das mal gezielt mit flac-Dateien testen.

7

Gute Frage. Da ich derzeit keine CBR-mp3 oder -mp2 habe, müsste ich mir die mal erzeugen und in die Playlist einpflegen. Aber im Live-Betrieb? Wohl kaum.

Die Verdachtsdiagnose kam auf, als ich las, dass Dateigrößenreduktion bei lossless-Dateien im Grunde nur mittels variabler Bitrate möglich sei. Zusammen mit Torbens früherem erhobenen Zeigefinger hinsichtlich VBR folgte ich dieser Spur.

Aus alten Threads las ich heraus, dass BASS vor allem Probleme hatte, beim Cue- und Mix-Editor das richtige Sample bei VBR-Dateien zu finden.
Backtiming war bislang aber noch kein Thema, wenn ich richtig gesucht habe.

Hinzu kommt, dass Torben sich früher™ gerne auch mal auf Rundungsfehler berufen hat, durchaus fortlaufend. Aber das sollte eigentlich keine Auswirkungen in dieser Dimension haben.

Mache ich bereits. Habe ich den Schlusstitel erst einmal festgelegt (das ist in meinen Sendungen nicht dynamisch wie bei dir neulich), dann wird in der Playlist sowohl Fade Out als auch Cue Out des letzten Titels entfernt. Dem folgt in der Playlist nur noch der Befehl ENCODER DISCONNECT als Link.
Allein deshalb darf der letzte Titel kein Fade Out haben, weil er ja Start Next bedeuten würde - und das dann eben zu früh.

Ich höre das bei meinen Radiokollegen immer wieder (die benutzen kein mAirList), die leider nicht darauf achten, wie und wann der Titel endet. Dann gibt es ein abruptes Ende der Übertragung zu Beginn des Crossfades oder wie das andere Programm das auch immer berechnet.
Unschön das ist.

Nennen wir es mal “bis zu…”, wie es findige Internetvertrags-Bandbreiten-Verkäufer am Telefon stets formulieren.
Und: Ja, im ASSIST, denn in der Automation würde das nicht auffallen (dort gibt es einen Puffer zwischen dem Timing “Normal” und “Backtimed”).

Ich nutze dein legendäres Backtiming-Script leider immer noch nicht, trotz Unterstützung von @calypso60. Irgendwas klemmt da, also wird der letzte Titel im Player mit erwarteter Endzeit angezeigt. Starte ich also auf Ende 19:59:59, kann ich gewissermaßen live zuschauen, wie sich das Ende sekundenweise nach hinten verschiebt.

Gute Idee.
Ich habe den lokalen Mitschnitt und die Aufzeichnung aus Hörerperspektive und eben das Original.

Werde ich prüfen.

Daran hege ich gewisse Zweifel. Zwar höre ich meistens den Einsatz von Soundverbiegern und hausgemachten Artefakten, aber was Geschwindigkeiten angeht, könnte ich mich täuschen lassen.

8

Nach meiner Erinnerung hatten wir die “Unterstützung” nicht komplett durchgespielt. Das können wir bei Gelegenheit gerne zu Ende bringen :slight_smile:

1 Like
9

Normalerweise haben die sie über die Zeit etwa auf, da mal auf- und mal abgerundet wird.
 

Meine Frage zielte darauf, ob die (allfällige) Spieldauerverlängerung mit einer Tonhöhenveränderung einhergeht (nach menschlichem Ermessen müßte sie das eigentlich, aber was heißt das schon?) oder eben nicht. Im direkten A-B-Vergleich zwischen den beiden Spuren müßte man das bei dieser Spreizung schon hören (6 % ≈ 1 Halbton).

10

Der angesprochene “dynamisch” festgelegte Schlusstitel war übrigens eine flac-Datei mit entsprechender Cue-Behandlung :thinking:

11

Nun ja… einerseits war er wohl ohnehin wohl recht kurz und zum anderen hast du ja das Backtiming-Script genutzt, das ihn erst spät eincued. Wie lange war das? 90 Sekunden?

Heute Abend habe ich zum Schluss einen Container, bestehend aus 3’02" flac und 1’10" mp3-Jingle. Mal sehen, was passiert.

12

Und, was ist bei diesem Versuch herausgekommen?

13

Bei der letzten Sendung war es lustigerweise eine Punktlandung (mit Schwankungen von +/- 1 Sekunde im EOF während des Abspielens). Morgen neuer Versuch.

14

Warum plus-minus? Es war genau ein Versuch, wie groß war die Differenz also? (Vermutlich meinst Du: weniger als eine Sekunde Abweichung.)

15

Ja, auch, aber eben nicht nur.

Während des Abspielens habe ich die geplante Endzeit stehen lassen und die wechselnde / springende Zeit im Auge behalten.
Die Endzeit wechselte zwischen 19:59:59 und 20:00:01, aber nicht darüber hinaus. Interessant dabei ist, dass die erwartete Endzeit nicht nur nach vorne lief, sondern auch mal zurück. Die Schwankungsbreite war geringer als bislang beschrieben, aber sie war sichtbar.

In dem Fall war es ein vierminütiger Container, bestehend aus zwei Elementen. Aber die Dauer des Containers war fix.

Heute um 20 Uhr kann ich neue Erfahrungen liefern.
Zum Glück ist nach mir keine pünktlich beginnende Sendung dran, sondern die Automation.

16

Könntest Du denn für Deine übernächste Sendung vor die entsprechenden Audios auf mp3/CBR konvertieren und nochmal beobachten? Dann dürfte, wenn unsere Vermutungen stimmen, der Effekt ja nicht auftreten.

17

Ich werde es mit einer extra dafür zusammengestellten Playlist im Testsystem machen. Dafür rippe ich schnell mal eine CD als cbr-mp3.
Bitte etwas Geduld.

Heute waren es fünf Sekunden:
Start bei erwartetem EOF 20:00:00, tatsächliches Ende um 20:00:05. Man konnte live zuschauen, wie die Sekunden zunahmen.

Gnarf. :face_with_raised_eyebrow:

18

Kein Problem. Danke füts Ausprobieren.