Reaper für Linux.

[hikaru]

Ich würde dir gerne nahelegen, dich zu informieren, bevor du sowas schreibst.

Hätte ich wohl machen sollen. Danke für den freundlichen Hinweis!

Ardour hängt nicht einmal von ffmpeg ab,

ardour-video-timeline hängt von ffmpeg ab. Warum?

und hat auch ’ne völlig andere Aufgabe und Funktion. Es ist ’ne DAW.

Wie wendet denn eine DAW ihre Änderungen am Quellmaterial an, um das Zielmaterial zu erzeugen? Irgendeine Art von Audioediting muss ja da spätestens bei der Audio-Ausgabe passieren.
Anders ausgedrückt: Wie werden aus den grafischen Editiervorgängen wieder Töne? Ich sehe, dass Ardour upstream u.A. von flac und libvorbis abhängt. [1] Ähnlich sieht es wohl bei Audacity aus. [2] Reicht das als Audio-Interface?

Audacity hängt übrigens ebensowenig von ffmpeg ab, auch nicht als Build-Dependency (wenn’s in Debian davon abhängen sollte, so war das die Entscheidung der Maintainer, kein Zwang seitens des Upstreams).

Audacity bringt im Quellcodearchiv einige ffmpeg-Header für dynamisches Linken mit, was aber aus Kompatibilitätsgründen optional ist. Als Alternative bietet es an, ffmpeg komplett aus dem System zu nehmen. Audacitys INSTALL-Script schreibt dazu das:

FFmpeg support::

Audacity should be able to link dynamically to FFmpeg 1.2 to 2.3.x (libav 0.8 to 10),
but many distributions have more recent versions that fail to link dynamically.
To work around this issue, Audacity may be configured to use the system
FFmpeg library and disable dynamic loading. If this is done for both FFmpeg
and the optional LAME library, the "Libraries" option in Audacity's Preferences
is not required and is automatically removed.
../configure --with-lib-preference="local system" --with-ffmpeg=system \
--with-lame=system --disable-dynamic-loading

Installierte Größen sind hier übrigens 50MB für Ardour, knapp 30MB für Audacity.

Appimages liefern die Software in komprimierter Form aus. Daher ergibt es Sinn, für Größenvergleiche die ebenfalls komprimierten Debianpakete heranzuziehen.


[1] https://nightly.ardour.org/list.php#build_deps
[2] https://wiki.audacityteam.org/wiki/Developing_On_Linux

[DeletedUserReAsG]

ardour-video-timeline hängt von ffmpeg ab. Warum?

Weil’s zum Vertonen von Videos ist, und als Audiosoftware (dafür steht’s A in DAW) keinerlei eigene Videofunktionalität mitbringt, sondern dafür auf ffmpeg zurückgreift. Hat mit dem eigentlichen Job von Ardour nix zu tun. Ist übrigens auch nur bei der Debian-Teilung (programm, programm-data, programm-zusätzlicher_Kram) von ffmpeg abhängig, bei der von mir verwendeten Distri, die in der Regel ziemlich nah am Upstream bleibt, gibt’s die Abhängigkeit nicht.

Wie wendet denn eine DAW ihre Änderungen am Quellmaterial an, um das Zielmaterial zu erzeugen? Irgendeine Art von Audioediting muss ja da spätestens bei der Audio-Ausgabe passieren.
Anders ausgedrückt: Wie werden aus den grafischen Editiervorgängen wieder Töne? Ich sehe, dass Ardour upstream u.A. von flac und libvorbis abhängt.

Ardour arbeitet intern mit ’nem eigenen, ziemlich coolen Audioformat. Ein- und Ausgabe erfolgt über die üblichen Schnittstellen: Jack und mittlerweile wohl sogar Pulse, die entsprechenden Libs werden eingebunden. libflac und -vorbis braucht’s für den Im- und Export. Nur eben ffmpeg wird, bis auf die Funktionalität mit dem Videokram, nicht gebraucht. Du solltest dir Ardour wirklich nicht als Frontend für irgendwas vorstellen – das ist’s nicht im Ansatz. Es sei denn, man bezeichnet ’ne Shell als Frontend für ncurses, oder ein DE als Frontend für das verwendete Toolkit.

Appimages liefern die Software in komprimierter Form aus.

Ich hantiere nicht mit Appimages, und möchte das auch nicht ändern. Die genannten Größen sind die Angaben der Paketverwaltung der von mir verwendeten Distribution für die installierte Größe der Pakete.

Was Audacity angeht: damit kenne ich mich nicht so aus – deswegen halte ich mich da bezüglich des Aufbaus zurück. Ich kann aber auch da mit Sicherheit sagen, dass es kein ffmpeg-Frontend ist. Was Ardour angeht, habe ich das damals™, als ich noch Debian auf dem Desktop hatte, ziemlich häufig selbst gebaut, weil ich die neusten Features haben wollte. Hab daher die Entwicklung einige Zeit recht aufmerksam verfolgt und ein wenig Überblick über dessen Aufbau und Funktion bekommen.