Beiträge von paddy78

  • Vbr Ac-3?

    Ok danke soweit! Aber im Grunde ist AC-3 doch framebasiert? Ich denke das ist was Eastermeyer auch mit "containerlos" meinte? Warum stellt es also ein Problem dar, Werte wie die Bitrate, die Anzahl der Kanäle usw. zu varieren?

    Also nach dem was ihr gesagt hab, gibt es im Grunde sowas wie VBR AC-3 nicht, aber theoretisch wäre es möglich. Ich muß mal schauen, ob ich diesen Thread wiederfinden kann in dem es auch um diese Thematik ging. Ich glaube da hatte jemand sogar geschrieben, dass es DVD`s gibt welche VBR AC-3 Daten enthalten.

  • Vbr Ac-3?

    Hallo!

    Ich weiß ich hatte mal in einem Artikel gelesen, das es wohl auch VBR AC3 Dateien geben soll. Weiß leider nicht mehr genau wo!

    Kann mir vielleicht jemand sagen, wo ich solche Dateien finden kann oder noch besser wie ich solche Dateien selber codieren kann?

    Sehr cool wäre auch wenn jemand Lust hätte, mir eine solche Datei zukommen zu lassen :cool: Per Email zum Beispiel.

    Thx
    Paddy

  • Zusätzliche Bytes zwischen AC3 Frames??

    hmmm also ich gehe mal davon aus das sauber demuxt wurde. wenn ich die files mit azid abspiele, dann meldet er ständig: W1: Found sync after 18 bytes.

    zum hintergrund: ich schreibe bzw. habe grade ein programm fertiggestellt, welches die metadaten eines ac3 files anzeigt. der aufbau dieser DVB-S AC3 dateien führt nun aber dazu, das die problematischen frames als fehlerhaft erkannt werden.

    bin da echt etwas ratlos.....ich mein ich könnte eine toleranz einbauen, jedoch erhöht das ja auch die wahrscheinlichkeit ein syncwort falsch zu detektieren.

    naja vielleicht hat ja jemand noch ne idee, aber ich fürchte das thema ist halt schon recht speziell......

  • Zusätzliche Bytes zwischen AC3 Frames??

    Hallo zusammen!

    Ich bin neu hier und hätte mal eine Frage an die "AC3 Experten" unter euch. Vielleicht kann mir ja jemand von euch weiter helfen??

    Also leg ich mal los: Wenn ich z.B. ein mit BeSweet codiertes AC3 File in einem Hex-Editor anschaue, so entspricht der Aufbau genau dem AC3 Standard, sprich jeder Frame beginnt mit dem Syncwort 0B 77, und wenn ich den Frame size code zusammen mit der Sample Rate entsprechend auswerte, bekomme ich die Anzahl der Bytes bis zum nächsten Syncwort. Positioniere ich also im Hex Editor den Cursor über den ersten 8 bit des Syncwortes (0B) und springe die ermittelte Anzahl an Bytes von dort aus weiter, so lande ich genau beim folgendem Syncwort und somit Frame.

    Nun habe ich zwei AC3 Dateien im Hex Editor analysiert, welche aus einer DVB-S Übertragung gewonnen wurden. Hier befinden sich jeweils immer 18 zusätliche Bytes zwischen den Frames, bzw. vor jedem Syncwort. Hier ein Beispiel:

    00 01 00 BD 1E 12 85 80 05 2F B4 5D FB 05 80 01 00 01 0B 77

    Wiederhole ich jetzt die obige Prozedur, also Positionieren des Cursors auf dem Syncwort und springen um die ermittelte Framegröße, so lande ich die ersten 4 Sprünge beim jeweils folgendem Syncwort. Beim 5. mal lande ich am Anfang der zusätzlichen 18 byte. Im obigen Beispiel wäre dies also die fett geschriebene "00". Diese Verhalten kann man die ganze Datei hindurch beobachten. Würde ich an dieser Stelle wieder manuell auf das Syncwort positionieren (18 byte nach vorne) und wieder die ermittelte Framegröße springen, so würde ich beim 5. mal springen wieder am Anfang der zusätlichen 18 byte landen. Ich kann mir dieses Verhalten nicht so recht erklären.

    Die Frage wäre nun ob mir jemand sagen kann, wozu hier 18 zusätzliche Bytes zwischen die Frames eingefügt werden, welche Infomationen diese beinhalten, und warum bei jedem 5. Sprung die aus dem Synchronization information header gewonnene Framegröße nicht korrekt ist und ich somit nicht am Anfang des folgenden AC3 Frame lande.

    Hoffe ich habe mein Problem einigermaßen verständlich rübergebracht....
    Also vielen Dank schonmal im Vorraus!!!

    greetz