Pal-Speedup mit mkv und ac3 Datei

  • Hallo,

    ich würde gerne mit einigen 24p mkv ein Pal Speedup machen, damit der Tv diese ruckelfrei wiedergeben kann.

    Bild und Ton habe ich schon getrennt.

    dann wollte ich mit belight den 5.1 acr Sound so strecken, dass die Tonhöhe erhalten bleibt.

    Nur leider finktioniert das mit 5.1 Sound anscheinend nicht.
    Mit Stereo geht es dann zwar, allerdings wird der Ton dann sehr leise und schlecht.

    Gibt es vielleicht mittlerweile bessere Tools für das Strecken ohne die Tonhöhe zu erhöhen? Es sollte sich schon vernünftig danach anhören.

    Vieleicht sogar für alles ein Tool?

    Wenn ich die Tonspur irgendwie mit erhaltener Tonhöhe getreckt bekäme, wäre alle paletti.

    Video und Ton dann mit mkvmerge wieder muxen und los gehts.

    Kennt jemand ein gutes Tool, mit dem ich den Sound so hinkriege?

  • Zitat

    Gibt es vielleicht mittlerweile bessere Tools für das Strecken ohne die Tonhöhe zu erhöhen?

    Für Stereo kenne ich Wavelab,da klappts bis auf die 3.Kommastelle genau und ohne Tonhöhenaenderung.
    Das Beste was ich kenne und auch einsetze.

    Für 5.1 könntest Du es mal probieren mit der Vorversion von Adobe Audition,also mit Cool Edit.

    Audacity ist kostenlos und kann auch viel.Obs Deinen Ansprüche genügt weiss ich natürlich nicht.

    Ev.gräbt User LigH noch was aus aus seinem Fundus.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Was meinst Du mit "auf die 2. Kommastelle genau"?
    Wird das dann wieder asynchron?

    Könntest Du mir kurz schildern, wie das genau mit Wavelab gemacht wird.

    Ich hätte jetzt erst mal eine 5.1 ac3

    Ich kann aber auch ne wav oder mp3 draus machen. Mit der ac3 wäre natürlich am praktischsten.:D

  • Zitat

    Wird das dann wieder asynchron?

    nein

    Wenn Du Wavelab hast dann hast doch auch ein Handbuch.

    Probiers erstmal so wie es oben Selur beschrieben hat.
    Ich arbeite in fast allen Fällen nur mit Stereo.

    Wavelab
    Wav laden
    Ctrl+ A
    "Ausführen" und dann erstmal normalisieren...
    "Ausführen" Zeitkorrektur

    fd5 [decodiert] - WaveLab_2011-11-04_14-00-27.png


    "Ausführen" Zeitkorrektur"

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • bei http://forum.gleitz.info/showthread.php…mrechnen-!HILFE! hab ich mal gepostet gehabt wie es geht, wobei die 0.95904 (PAL->NTSC) sich durch To/From (also 23.976/25) ergibt und hier entsprechend angepasst werden müsste (auf To/From = PAL/NTSC = 25/23.976 = 1.042709)

    Cu Selur

    Ps.: Kommt WavLab eigentlich mit 5.1 wav klar und ein reencoding nach ac3 muss dann auch noch gemacht werden, oder kann wavlab das selber?

  • Selur, könntest Du mir Dein Beispiel erläutern?

    Zitat

    ffmpeg -v -10 -i "inputPAL.ac3" -acodec pcm_s16le -ac 2 -ar 48000 -f wav - | sox -t raw -e signed-integer -2 -c5 -r48000 - -t wav - speed 0.95904 | aften -b 576 - "outputNTSC.ac3"

    1.) Warum bei ffmpeg "-ac 2", bei SoX aber "-c 5"? Und warum nicht 6 (5.1) Kanäle?
    2.) Warum bei ffmpeg "-f wav", aber bei sox "-t raw"? Müßten nicht entweder beide auf wav oder beide auf pcm/raw gestellt werden?
    3.) "speed" ist mit, "tempo" ohne Tonhöhenänderung, korrekt?
    4.) Zumindest mit Tonhöhenänderung wäre nur mit eac3to ja wesentlich einfacher, oder spricht etwas dagegen?
    5.) "-v" ??
    6.) "-10" ??

  • Nachtrag zu 2.)
    Habe gerade folgendes gefunden(, aber noch nicht getestet):
    http://pastebin.com/SJW0YPLF

    Könnte die Operation nochmal gut vereinfachen.
    Müßte dann in etwa so aussehen:

    Zitat

    ffmpeg -i "input24.ac3" -f sox - | sox -t sox - -t wav - tempo 1.04270 | aften -b 576 -readtoeof 1 - "output25.ac3"

    Wie genau kann/darf/sollte man den factor wählen? Sind auch Brüche erlaubt?

    /edit: eac3to-Parameter nach Eingabe-/Ausgabedatei.
    /edit2: eac3to mit aften ersetzt, da eac3to keine pipe als Eingabe nimmt. Klappt aber in meinem Test immer noch nicht....
    /edit3: readtoeof korrigiert

    4 Mal editiert, zuletzt von sneaker2 (4. November 2011 um 17:23)

  • HuHA, da ist ja einiges verquer. ;)
    Hier mal eine korrekte Version wie ich sie in Hybrid verwende und wie sie unter Windows/Mac/Linux funktioniert:

    Code
    ffmpeg -threads 8 -v -10 -y -i "input.ac3" -ac 6 -acodec pcm_s16le -f s16le - | sox --ignore-length --temp "D:\Encoding Temp" --buffer 2097152 -S -t raw -e signed-integer -2 -c6 -r48000 - -t wav - speed 1.04271 | aften -v 2 -readtoeof 1 -b 576 - "output.ac3"


    Zu den Parametern:

    bei ffmpeg:

    • -threads 8
      legt fest das 8 threads verwendet werden dürfen (stelle ich i.d.R. auch die Anzahl der Cores der CPU ein die verwendet wird), kann auch weggelassen werden
    • -v -10
      deaktiviert jegliche Ausgaben (wichtig, damit hicht etwas per Pipe an sox übergeben wird was da nicht hin soll)
    • -y
      legt fest, dass der Output überschrieben werden darf (kann man auch weg lassen, ist da nur weil ich es immer bei meinen ffmpeg Aufrufen verwende)
    • -i "..."
      zeigt was der Input ist
    • -ac 6
      gibt an wie viele Kanäle der Ton hat (kann man auch weg lassen, wenn man sicher ist, dass ffmpeg die Kanalanzahl richtig erkennt, schreibe ich persönlich aber immer hin)
    • -acodec pcm_s16le
      legt fest, dass der Outputstream als PCM signed 16bit little endian codiert werden solll
    • -f s16le
      legt fest, dass die Header/der Container signed 16bit little endian codiert ist


    siehe auch: http://ffmpeg.org/ffmpeg.html

    bei sox:

    • --ignore-length
      sorgt dafür, dass der Input bis zum Ende gelesen wird, was nötig ist da eine RAW Pipe keine Länge enthält; bei wav wäre es anders, aber zwecks CrossPlattform-Kompatibilität verwende ich lieber RAW PCM)
    • --temp "..."
      legt fest, wo eventuelle Temporäre Dateien gespeichert werden; kann weg gelassen werden
    • --buffer 2097152
      legt fest wie groß der Inputbuffer ist; der Wert passt bei mir bis dato ganz gut
    • -S -t raw -e signed-integer -2 -c6 -r48000 -[/*]
      legt das input format fest: -S = hab ich vergessen; -t raw = RAW Audio; -e signed-integer -2 = hab ich vergessen; -c6 = 6 Kanäle in Input stream; -r48000 = Input stream hat eine Sampling rate von 48kHz; - = Input kommt via Pipe rein
    • -t wav -
      -t wav = Output ist wav; - = Output wird an std::out ausgegeben
    • speed 1.04271
      Speedup um Faktor 1.04271


    siehe: http://sox.sourceforge.net/soxi.html

    bei aften:

    • -v 2
      legt fest was für Ausgaben auf der Konsole stattfinden sollen
    • -readtoeof 1
      Input wird bis zu Ende eingelesen, also unabhängig von irgendwelchen Längen die im wav Header stehen, da sox den Wert nicht kennt
    • -b 576
      legt die Bitrate auf 576 kBit/s fest.
    • -
      sagt, dass der Input per Pipe ankommt
    • "output.ac3"
      legt den Output fest


    siehe: aften -h

    Zitat

    Sind auch Brüche erlaubt?


    Nein, nur Floats/Integer.

    ----------------------------
    Sneaker:
    1. sox als Übergabeformat verwende ich i.d.R. nicht, da hier die Werte übergeben werden die ffmpeg ermittelt, welche leider aber nicht immer korrekt sind, gerade was die Samplerate angeht.
    2. bei aften würde ich empfehlen noch '-readtoeof 1' zu verwenden

    Cu Selur

  • -v -10
    deaktiviert jegliche Ausgaben (wichtig, damit hicht etwas per Pipe an sox übergeben wird was da nicht hin soll)

    Die scheiß ffmpeg-doc kennt "-10" nicht, aber ich denke mal, daß es synonym für "quiet" ist? Wußte garnicht, daß das bei pipes Probleme machen kann, bzw. ich selbst hatte noch nie entsprechende Probleme. (edit: "-v" ist als "deprecated" gelistet, man soll nun "-loglevel" nutzen.)

    --ignore-length
    sorgt dafür, dass der Input bis zum Ende gelesen wird, was nötig ist da eine RAW Pipe keine Länge enthält; bei wav wäre es anders, aber zwecks CrossPlattform-Kompatibilität verwende ich lieber RAW PCM)

    Ist es nicht umgekehrt, also nur bei wav nötig, da am Anfang der header geschrieben wird, wenn man noch gar nicht weiß, wie lang die Ausgabe ist?

    -S -t raw -e signed-integer -2 -c6 -r48000 -
    legt das input format fest: -S = hab ich vergessen; -t raw = RAW Audio; -e signed-integer -2 = hab ich vergessen; -c6 = 6 Kanäle in Input stream; -r48000 = Input stream hat eine Sampling rate von 48kHz; - = Input kommt via Pipe rein

    Ok, -2=2 Byte = 16 bit
    -S = −−show−progress

    1. sox als Übergabeformat verwende ich i.d.R. nicht, da hier die Werte übergeben werden die ffmpeg ermittelt, welche leider aber nicht immer korrekt sind, gerade was die Samplerate angeht.

    Ok, werd' ich im Hinterkopf behalten. Besteht die Chance, daß das inzwischen gefixt wurde?


    Aber danke schonmal, das bringt einen wesentlich weiter. Allerdings müßte es doch für den Threadstarter "tempo" anstatt "speed" sein, oder? (Siehe mein anderer Beitrag)

    Ein paar Sachen noch:
    6.) Gibt es einen bestimmten Grund, warum Du zwischen ffmpeg und SoX PCM, zwischen SoX und aften aber wav nimmst?
    7.) Kann SoX "tempo" auf Mehrkanalton korrekt anwenden? Bei AviSynth's timestretch() gibt es ja Probleme.
    8.) Wie müßte ich den Faktor für "pitch" wählen, wenn ich nur diesen korrigieren möchte? Der war z.B. bei der ersten Pressung der Herr der Ringe SEE-Blu-Rays zu niedrig (slowdown mit Tonhöhenänderung).

    Einmal editiert, zuletzt von sneaker2 (4. November 2011 um 18:04)

  • Zitat

    Die scheiß ffmpeg-doc kennt "-10" nicht, aber ich denke mal, daß es synonym für "quiet" ist? Wußte garnicht, daß das bei pipes Probleme machen kann, bzw. ich selbst hatte noch nie entsprechende Probleme. (edit: "-v" ist als "deprecated" gelistet, man soll nun "-loglevel" nutzen.)


    Ja, sollte synonym für '-loglevel quiet' sein. (die -10 hab ich vermutlich im Sourcecode nachgeguckt gehabt ;))
    Werde erst mal noch -v verwenden, da es zwar deprecated aber noch unterstützt ist und ich so auch mit alten ffmpeg Versionen kompatibel bin. ;)

    Zitat

    Aber danke schonmal, das bringt einen wesentlich weiter. Allerdings müßte es doch für den Threadstarter "tempo" anstatt "speed" sein, oder? (Siehe mein anderer Beitrag)


    speed passt den pitch an, tempo nicht -> würde einfach beides mal testen und gut ist :)

    Zitat

    Ist es nicht umgekehrt, also nur bei wav nötig, da am Anfang der header geschrieben wird, wenn man noch gar nicht weiß, wie lang die Ausgabe ist?


    ffmpeg wüsste ja die Länge, da es noch die Inputdatei kennt. --ignorelength sollte man immer bei PipeInput nehmen, bei dem man sich entweder nicht auf die Länge in den Headern verlassen will/kann oder bei denen man weiß, dass keine Länge in den Headern steht bzw. keine Header existieren und somit die Länge nicht gewusst werden kann. ;)

    Zitat

    Ok, werd' ich im Hinterkopf behalten. Besteht die Chance, daß das inzwischen gefixt wurde?


    Ja, da kann ich mich in Hybrid aber nicht drauf verlassen, da die Leute da nicht immer ne aktuelle Git/SVN Version haben. ;)

    Zitat

    Gibt es einen bestimmten Grund, warum Du zwischen ffmpeg und SoX PCM, zwischen SoX und aften aber wav nimmst?


    ffmpeg->sox nehme ich PCM weil ich mit wav schon Probleme unter Linux hatte
    sox->aften nehme ich wav, weil aften wav will :)

    Zitat

    Kann SoX "tempo" auf Mehrkanalton korrekt anwenden? Bei AviSynth's timestretch() gibt es ja Probleme.


    Meiner Erfahrung nach: Ja, zumindest habe ich bis dato noch nichts gehabt, was sich 'merkwürdig' anhört, nutze die Option aber wirklich nur zum Testen, da ich eigentlich nie Normwandlungen mache, oder die mache ohne den Ton zu ändern. :)

    Zitat

    Wie müßte ich den Faktor für "pitch" wählen, wenn ich nur diesen korrigieren möchte? Der war z.B. bei der ersten Pressung der Herr der Ringe SEE-Blu-Rays zu niedrig (slowdown mit Tonhöhenänderung).


    Keine Ahnung, hat mich schon Wochen gekostet das Bißchen so verstehen und anzutesten was ich mit sox so mache. (meist Downmixes) Gibt ja nicht wirklich Leute die einen mit sox helfen können und wollen und meine Kenntnisse im Audiobereich sind auch sehr mager,... (vor allem weil das Interesse und die Notwendigkeit nie bestanden hat sich da groß Einzuarbeiten,.. hab mir ein paar Sachen erarbeitet die ich in Hybrid anbiete, weil es User angefragt haben, aber das war es Leider auch schon)

    Cu Selur

  • ffmpeg wüsste ja die Länge, da es noch die Inputdatei kennt.

    Hmmmm.... klingt einleuchtend.

    Alles klar, Danke. Bin jetzt auch soweit, daß es hinhaut. Hatte bis jetzt SoX immer vermieden, weil es doch recht kompliziert für Einsteiger ist, aber letztendlich kommt man doch nicht immer drumherum. Als Einstieg war das schonmal recht gut.


    • [...]
    • -acodec pcm_s16le
      legt fest, dass der Outputstream als PCM signed 16bit little endian codiert werden solll
    • -f s16le
      legt fest, dass die Header/der Container signed 16bit little endian codiert ist


    [...]
    siehe auch: http://ffmpeg.org/ffmpeg.html

    Hi, der Thread ist zwar etwas älter, aber immernoch hilfreich ;)

    Aber eine Frage hätte ich da noch. In einem ähnlichen Fall (da gings um die Pipe ffmpeg | qaac) wurde im doom9 Forum empfohlen, anstelle von 16bit für die Pipe 32bit (im speziellen pcm_f32le) zu nutzen, um Rundungsfehler zu vermeiden/verringern.
    Wäre dies in diesem Fall nicht auch (zumind. theoretisch) sinnvoll?
    Und eine weitere theoretische Frage: Spielt es Qualitätsmäßig eine Rolle, ob man signed, unsigned oder float verwendet? Also ob man pcm_s32le, pcm_u32le oder pcm_f32le? Sind ja schließlich 32bit Zahlen. (natürlich vorausgesetzt, das der Empfänger damit korrekt umgehen kann)

    Edit: und gleich noch eine Frage hinterher: Spricht irgendwas dagegen, für ffmpeg und sox als Format ebenfalls wav zu nehmen? Also wär prinzipiell folgende Kommandozeile ansich ebenfalls in Ordnung oder würde die Mist produzieren? Immerhin, es fällt Mehrkanal-ac3 hinten raus^^

    Code
    ffmpeg -loglevel panic  -i "audio_input.dts" -c:a pcm_f32le -f wav - | sox  --ignore-length -t wav - -t wav - speed 1.04271 | aften -v 2 -readtoeof 1 -b 576 - "audio_output.ac3"


    Edit 2: und weiter gehts^^
    mache ich den PAL-Speedup mittels eac3to, sagt mir dieses in meinem Fall:
    "Clipping detected, a 2nd pass will be necessary."
    Spielt das bei ffmepg | sox | aften keine Rolle oder wird das Clipping da irgendwie "on the fly" korrigiert?

    2 Mal editiert, zuletzt von qupfer (16. August 2014 um 10:50)

  • Zitat

    Wäre dies in diesem Fall nicht auch (zumind. theoretisch) sinnvoll?


    Kommt Darauf an ob der Encoder der verwendet wird auch 32bit pcm unterstützt, was die meisten tools nicht machen. (+ ist i.d.R. wirklich nur ein theoretischer gewinn)

    Zitat

    Spielt es Qualitätsmäßig eine Rolle, ob man signed, unsigned oder float verwendet?


    Ne, so lange alle beteiligen Tools wissen was durchgereicht wird und sie damit umgehen können ist es egal. (i.d.R. wird aber signed verwendet)
    Im 8bit Fall:
    signed = Wertebereich -127 - 127
    unsigned = Wertebereich 0-255
    -> gleiche Anzahl von Elementen :)

    Zitat

    Spricht irgendwas dagegen, für ffmpeg und sox als Format ebenfalls wav zu nehmen? Also wär prinzipiell folgende Kommandozeile ansich ebenfalls in Ordnung oder würde die Mist produzieren?


    Bei neueren ffmpeg Versionen sollte es keine Probleme geben, bei älteren ffmpeg versionen ist sox zu empfehlen, da die wav Übergabe bei älteren Versionen nicht immer einwandfrei war.
    -> würde allein aus Kompatibilitätsgründen sox oder raw PCM empfehlen, wobei letzteres den sox Aufruf aufblähen würde, weil man dann genau angeben muss was für Samplerate&Co vorliegt. (raw = keine Header)

    Zitat

    Spielt das bei ffmepg | sox | aften keine Rolle oder wird das Clipping da irgendwie "on the fly" korrigiert?


    Kann durchaus eine Rolle spielen, weshalb ich i.d.R. noch ein '-n' drann packen würde. Lies mal: [Info] Understanding the audio gain methods,....

    Cu Selur

    Hybrid hier im Board, Homepage (http://www.selur.de), Forum

    Wünsche allen ein paar fröhliche Weihnachtstage!

    Einmal editiert, zuletzt von LigH (17. August 2014 um 11:26) aus folgendem Grund: quote

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!