mit FFMpeg audio extrahieren oder umwandeln

Kleine Hilfestellung wie man mit Hilfe von FFMPEG Audio aus Videos in verschiedene Formate bekommt.

mit FFMpeg audio extrahieren oder umwandeln

Eins muß man vorher wissen: „Besser“ wirds durch erneutes Kodieren nicht!

Wer kennt das nicht, man zieht ein Video von YouTube, weil man die Musik gut findet und will ein reines Audioformat daraus machen. Da müssen wir uns erst einmal ansehen, was dann in der Datei drin ist:

ffprobe -i video.webm

Da könnte dann z.b. rauskommen:

Stream #0:1[0x2](und): Audio: aac(LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 159 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]

Da alle Linux Audioplayer, die ich so im Einsatz hatte, aac direkt abspielen können, müssen wir das gar nicht groß umkodieren:

ffmpeg -i video.webm -c:a:0 copy -f aac audio.aac

Das Ergebnis kann man gleich abspielen. Das Gleiche gilt für Opus, was man auch häufig antrifft (erst nachsehen!):

ffmpeg -i video.webm -c:a:0 copy audio.opus

Will man das als MP3 haben, muß man erst abschätzen, wieviel Bitrate sinnvoll ist, weil AAC oder OPUS besser kodieren als MP3 und somit weniger Bitrate ( kb/s ) brauchen als ein vergleichbares MP3. Da bietet es sich an, daß LAME selbst festlegen zu lassen und erst einmal ein verlustfreies WAVE daraus zu machen:

ffmpeg -i file.webm file.wav

und dann mit LAME ein VBR MP3 mit variabler Bitrate zu machen, da sucht sich der Codec die beste Qualität selbst aus:

lame -V 0 -b 64 -B 320 -q 0 file.wav file.mp3

Wenn man etwas weniger Platz benötigt und mit ein paar Verlusten leben kann, dann geht’s auch mit einem kleineren Maximalwert:

lame -V 0 -b 64 -B 224 -q 0 file.wav file.mp3

Das hängt eben auch damit zusammen, wie gut das Original war, falls man bei YT Videos von „Original“ sprechen kann, die ja auch nur durchgenudelt werden bis zum Gehtnichtmehr 😉 Deswegen immer dran denken: es kann nicht besser werden als die Qualität im Video, egal wie Hoch Ihr die Maxbitrate auswählt für euer MP3 oder AAC [da gibts auch Bitraten bis 512kb/s]. Wenn Ihr „ffmpeg -c:a:0 copy“  einsetzen könnt, tut es, dann wird es nicht schlechter.

 

Linux am Dienstag – Programm für den 1.7.2025

Diesmal bei Linux am Dienstag bekämpfen wir das Sommerloch mit Einblicken in die Welt der DJs.

Linux am Dienstag – Programm für den 1.7.2025

u.a. im Programm am 1.7.2025, ab 19 Uhr :

  • Sommerloch – der „bunte“ Abend ohne Weißabgleich
  • Audio – Streaming mit Icecast (Marius)
  • Audio – DJ Software MIXXX im Einsatz (Marius)
  • Sicherheit – hunderte Brotherdruckermodelle mit Sicherheitslücke
  • Sicherheit – BT Kopfhörer mit Airoha Chips können übernommen werden

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .
Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

An manchen Tagen komme ich mir vor, als wenn ich eine Linuxwerkstatt hätte, statt einen PC mit einer Stableversion von Fedora. Da bin ich öfters im Redhat Bugtracker als auf meiner eigenen Webseite.

Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

Der.. nein, sagen wir lieber „ein“ aktueller Fall in der Werkstatt ist das Unvermögen von Firefox Netflix über Wochen sauber abzuspielen ohne Probleme auf die oder andere Art zu produzieren.

Was war geschehen?

Am 2. Mai hatte Firefox beschlossen, daß ich zwar von Netflix den Ton hören dürfte, aber das Video wäre jetzt Privatsache vom Videodecoder. Die Bilder stockten also, insgesamt war alles im Firefox zäh wie Sirup. Die Probleme mit Netflix dauerten auch bis in den nächsten Tag an, wobei auch Webseiten sirupartig waren. Auf einem Ryzen 5600 mit RTX 4060 ist das eher kein Hardwareproblem.

Der Verdacht lag nahe, daß Firefox statt die GPU zu verwenden beschlossen hatte die CPU die ganzen bunten Dinge berechnen zu lassen, was zu immensen Performanceproblemen führen würde. Nach ein paar Stunden des selben Tages gab sich das Problem, was aber nicht an Firefox lag wie sich rausstellte.

Da es ein gstreamer Update gab, daß zeitlich korrelierte, habe ich mal ein Ticket im Bugzilla von Redhat aufgemacht, prompt hat sich da ein anderer User gemeldet, der ähnliche Probleme mit Firefoxplayback auf einer AMD RT 6800 hatte.

Die Zeit vergeht… alle sind ratlos

Die zeit vergeht, alle sind ratlos, dann schlägt das Schicksal erneut gnadenlos zu: Letzte Nacht stoppt Netflix mit dem gleichen Problem während ich ein Video mit OpenShot geschnitten habe. Also erstmal Firefox neugestartet, aber das half nichts. Dann gesagt: „nicht so wichtig“ und mich ums Video gekümmert. Das habe ich mir mit Celluloid ansehen wollen und was muß ich feststellen? Kein Videoplayback, nur Ton. „Oh oh“

Nichts geht mehr

Celluloid, MPV, Totem produzierten ALLE das gleiche Muster, nicht mal die Fortschritte auf den Zeitskalen wurden durchgezählt, die Videos zeigten nur das erste Bild vom Video was üblicherweise Schwarz ist, so daß man das nciht direkt merkt. Zum Glück hatte ich ein anderes Video das direkt ein Bild da hatte. Skippe man im Video rum, kamen auch anderen Standbilder raus.

Um Kernelprobleme auszuschließen habe ich rebooted, aber das half rein gar nichts. Alle Videoplayer zeigten das gleiche Bild ( sprichwörtlich ) … „wirklich alle?“ Nein, ein kleiner, oft völlig unbedachter Videoplayer trotzte dem Problem und spielte weiterhin alle Videos perfekt ab. Und an dem Punkt geht einem ein Licht auf.

Der Player war FFPLAY from FFMPEG Paket. Das heißt, alle anderen Videoplayer und Firefox müssen etwas gemeinsam haben: Pulseaudioplayback.

Der Workaround

Ums Kurz zu machen: sobald jemand via Pulseaudio auf das den HDMI Ausgang meiner Nvidiakarte wollte, stockte das Video, aber der Ton ging sauber durch, was  völlig GAGA ist, weil das kein bisschen was mit Grafiken zu tun hat.

Ich denke folgendes ist passiert: Pipewire läuft ja unter der Haube von Pulse und ist für Video und Audio zuständig. Das hat ein Problem mit dem HDMI Device gehabt. Das muß aber in der User-Config persistent gespeichert sein, also quasi blanker Unsinn im State File oder so etwas in der Art, weil es ja rebootfest war und das geht nur, wenn sich jemand den „Zustand“ von dem Device irgendwo auf der Platte merkt!

Ich habe dann einfach mal das Device via PulseAudio-Lautstärkeregler abgeschaltet, so daß alle Audiostreams über das Mainboard liefen und was soll ich sagen : 100% alle Probleme verschwunden. Alle Player funktionierten wieder 1a.

Nach dem das Ausgabegerät wieder auf dem selben Weg eingeschaltet wurde, liefen die Player auch mit dem HDMI Gerät wieder einwandfrei.

Im Bugtracker wird fleißig am Problem gearbeitet, sollte also bald gefixt sein.