Handbuch: BeSweet-Kommandozeilenreferenz

Hi @ll.

In der einen oder anderen Form verwenden wir wahrscheinlich alle BeSweet. Trotz der sehr guten GUIs dafür fand ich es schon immer schade, dass keine komplette Referenz der Kommandozeilenparameter existiert. Besonders Doku auf deutsch ist in dem Bereich ja kaum zu finden.
Das soll sich ändern! Deshalb habe ich mich jetzt hingesetzt und ein BeSweet-Handbuch gebaut.

Inzwischen ist die Referenz in der Finalversion verfügbar. Aktuelle Version immer hier: http://brother-john.net/besweet-referenz.html
Eine Online-Version gibts im Gleitz-Wiki: BeSweet-Referenz (muss nicht unbedingt identisch sein).

----------
Rest vom ursprünglichen Posting:
----------
Es ist noch keine endgültige Version, aber weit genug gediehen, um mal eine Vorabversion online zu stellen. Denn jetzt brauche ich Feedback! Also führt euch das Ding zu Gemüte und sagt mir, was gut/schlecht/falsch daran ist. Was sollte zusätzlich noch rein, was sollte vielleicht raus...
Besonders dankbar wäre ich, wenn mir jemand Azids »Dialog normalisation reduction« in laienverständlichen Worten erklären könnte. Die Funktion habe ich noch nie so richtig kapiert.

Ach ja, der Link: <alten Link entfernt>

P.S.: Diese Referenz ist ausdrücklich nicht für Einsteiger gedacht. Wer gerade mit dem Encoding anfängt, sollte imo erst einmal eine GUI verwenden.

Thx für die Blumen. Was soll ich denn auch machen außer Anleitungen schreiben? Coden kann ich nicht, und beim Posten ist LigH immer schneller.

Da mich der Stress heuer größtenteils verschont hat und da natürlich ein paar Minuten Freizeit übrig bleiben: Wie wärs mit einer neuen Version als Weihnachtsgeschenk? - "Release Candidate 1" oder auch "Santa Edition".
(Kann man Archive erstellen, die sich erst am 24.12. öffnen lassen? :zunge: )

BeSweet-Referenz 2004-12-21 RC
Wenn ich nur im Detail noch wüsste, was sich alles geändert hat... war ne ganze Menge.
Ha, jedenfalls denke ich, jetzt die "Dialog Normalization Reduction" kapiert zu haben. Dazu kann ich diese beiden Threads empfehlen, v.a. den ersten:
http://forum.doom9.org/showthread.php?s=&threadid=25293
http://forum.doom9.org/showthread.php?s=&threadid=32814

Und damit erstmal Frohes Fest - lasst euch ruhig Zeit mit dem Lesen. Eine Final-Version noch heuer halte ich für unwahrscheinlich. Zwischen Weihnachten und Neujahr bin ich zu sehr damit beschäftigt, die Gans zu verdauen, mit Stollen und Plätzchen nachzufüllen und das Ganze dann Silvester in geselliger Runde mit dem einen oder anderen Bierchen runterzuspülen.

Erstmal ein Dankeschön für das Feedback. Freut mich, wenn sich schon mal keine groben Schnitzer eingeschlichen haben.

Zitat von akapuma

3.1.1 Normalisierungsparameter -norm
Hier würde ich noch darauf hinweisen, daß "echtes" PreGain einen zusätzlichen Durchlauf benötigt.

Ok. Spätestens beim Transcoding kriegt es zwar jeder sowieso mit, aber ein Hinweis kann ja nichts schaden.

Zitat von akapuma

-hybridgain
Hier besteht meiner Meinung nach Verwechslungsgefahr.

Wie wärs hiermit: »Kombiniert einen festen Pre-Gain-Wert und Post-Gain-Normalisierung, abhängig vom Format der Quell- und Zieldatei.«
LigH, Hybridgain post-gain-normalisiert auf 97%. Änderbar ist der Wert nicht, da hast du recht.

Zitat von akapuma

hinweisen, daß der -r-Parameter bei -soundtouch vielleicht bessere Ergebnisse liefert als bei -ota

Wusste ich bisher nicht, dass soundtouch bessere Quali liefert. Ich werd’s erwähnen.

Zitat von akapuma

Hier hatt OggDrop eine Qualitätsskala von -1 bis 10. Daher habe ich mal BeSweet mit negativen Parametern gestartet:

Thx fürs Testen. Kommt natürlich mit rein.

Zitat von akapuma

Sollte man hier von VBR sprechen? OggDrop nennt den Modus nicht VBR, sondern "Quality Management Mode".

Deswegen schreibe ich ja »echtes« VBR im Vergleich zu ABR – das wäre dann wohl »nichtganzsoechtes« VBR ;). Wer den Unterschied zwischen den drei Encodingmodi (VBR CQ, ABR, CBR) nicht kennt, sollte eh erst einmal andere Doku als die Referenz lesen. Eine kleine Präzisierung kann trotzdem nichts schaden: »Vorbis ist stark auf echtes VBR im Constant-Quality-Modus ausgerichtet, deshalb sollte möglichst...«

Zitat von akapuma

Naja, wenn mal die Langeweile kommt

In dem Fall hat das mit Langeweile nichts zu tun. Da man in 99% aller Fälle mit zusätzlichen Lame-Optionen nur schlechtere Ergebnisse produziert, spreche ich sie erst gar nicht an. Wer eine zusätzlich Option wirklich gezielt und sinnvoll einsetzt, der hat genug Ahnung, um das ohne Referenz hinzukriegen. Alle anderen (da zähle mich mich selbst absolut dazu) sollten von den Schalterchen lieber die Finger lassen.

MP2-Encoder: Ob mp2enc oder toolame besser ist, würde mich auch interessieren. Da ich in meinem Leben außer zu Testzwecken noch keine MP2 erstellt habe, bin ich da reichlich ahnungslos.

ac3enc: Meine Erfahrungen beim AC3 erstellen unterscheiden sich nicht besonders von denen mit MP2. Wenn ich auf Doom9.org rumlese, finde ich geteilte Meinungen. Ich werde noch ein paar Tests machen.
Sehe ich das richtig, dass es mindestens 2 Versionen der dll gibt: Die von BeSweet und die von HeadAC3he? Sind das alle?

Zitat von LigH

Die Spuren 0x89-0x8F sind reserviert für "Tonformate, die direkt digital an einen externen Decoder zu schicken sind"

Um ehrlich zu sein: Die Nummern hab ich einfach aus der BeSweetGUI abgeschrieben ;). Formulieren wir ein bisschen um: »Auf der DVD befindet sich üblicherweise AC3 in den Spuren 0x80 bis 0x88, PCM in 0xA0 bis 0xA7 und MPEG-Audio in 0xC0 bis 0xC7. Die Spuren 0x89 bis 0x8F sind für alternative Tonformate wie DTS gedacht.«
Oder: »... sind für optionale Tonformate ...«?

Zitat von akapuma

da viele bereits vorhandene/bekannte BeSweet-Parameter in der Referenz vielleicht vergebens suchen, könnte man vielleicht eine Vergleichs-Referenz dazutun?

Das lässt sich machen. Mann, ich verwende seit eh und je -ssrc() und kaum steht in der Doku was anderes, vergesse ich die gewohnte Alternative...

Damit verabschiede ich mich erstmal. Den Rest vom Jahr bin ich wahrscheinlich nicht mehr online. Lasst euch keine Raketen auf den Kopf fallen und ertrinkt nicht im Sektglas. Guten Rutsch!

Prost 2005!
Ich werde wieder bis Mitte Juni brauchen, bis ich mich bei der Jahreszahl nicht mehr verschreibe :hm:.

Zitat von LigH

Ja, klingt gut. Ansonsten, mein Vorschlag für die andere Textstelle:

Gefällt mir. Ich habs ein wenig gestrafft, um den Fokus so wenig wie möglich von BeSweet abzulenken:
»Die Spuren 0x89 bis 0x8F sind für optionale Tonformate wie DTS gedacht, die Standalone-Player ohne passenden Decoder digital ausgeben oder ignorieren.«

Zitat von LigH

Ich weiß nicht, ob die DLL von HeadAC3he von BeSweet benutzt werden kann. Was ich meinte, ist: Eine DLL im Archiv der 1.5b29 (von der Beta-Seite) mit beiliegend; eine weitere in einem eigenen Archiv (von der Plugins-Seite).

Die HeadAC3he-DLL geht leider nicht. Die DLL von der Plugins-Seite ist deutlich älter als die im Archiv von BS 1.5b29. Die Ergebnisse sind mit beiden die gleichen.

Das habe ich herausgefunden:
Bei Gain/Normalisierung über OTA wird die AC3 deutlich zu leise. Sieht ganz so aus, als würde OTA in dem Fall einfach ignoriert. Gain/Normalisierung über Azid funzt.

-azid( -g max ) -ac3enc( -6ch -b 384 )

So wird die Ziel-AC3 spürbar lauter als die Quell-AC3 (DVD-Tonspur 6ch 448 kbit). Nach etwas spielen bin ich darauf gekommen, dass

( -g [b]0.30[/b] ) -ac3enc( -6ch -b 384 )

subjektiv in etwa die Lautstärke der Quelle erzeugt. Kann das jemand bestätigen?
Da AC3 ja beim Pegel einige Tricks auf Lager hat, bin ich mir auch nicht sicher, ob die lautere Zieldatei wirklich ein Problem/Bug ist. Vielleicht codiert ac3enc einfach nur ohne große Pegel-Spielereien? Soweit ich das an den kurzen Testencodings feststellen kann, ist jedenfalls die volle Dynamik nach wie vor da.
==> Da DSPguru die ac3enc.dll ja nicht ohne Grund wieder mitliefert, kommt die Warnung raus und der Hinweis rein, nicht per OTA zu normalisieren. Vielleicht zusätzlich etwas wie: »Vorsicht, ac3enc befindet sich in der Entwicklung und könnte evtl. Probleme verursachen bzw. fehlerhafte AC3s erzeugen.«

Zitat von akapuma

ich weiß es auch nicht, ich habe -r noch nie verwendet. Ich hatte es nur Aufgrund Deiner Beschreibung und der allgemeinen Freude, als soundtouch rauskam, vermutet.

Diesem Thread von bond nach zu urteilen, hat soundtouch tatsächlich die Nase vorn. Mag sein, dass der Test wirklich nicht - wie DSPguru meint - der akkurateste war. Für eine grobe tendenzielle Aussage zugunsten von soundtouch reicht es imo aus.

Und dann habe ich hier noch das gefunden:
note that soundtouch does not support multichannel audio, only mono and stereo
Muss ich morgen mal testen, auch im Vergleich zu OTA.

Update. Noch ein bisschen Kosmetik, Rechtschreibfehler etc. korrigieren, dann würde ich die Referenz als fertig bezeichnen.
Mich plagt immer mehr der Gedanke einer Übersetzung. Ich glaube, auch international würden sich einige über eine komplette Referenz freuen. Wenn nur die Klausuren nicht so bedrohlich näher rücken würden.

BeSweet-Referenz 2005-01-03 RC

Hier eine Liste der Änderungen, damit der Überlick nicht verloren geht.
~~~~
- im Thread angesprochene Änderungen
+ noch nicht besprochene Änderungen
~~~~

core
- VOB-Streamnummern korrigiert.

OTA
- Normalisierung: 2-Pass erwähnt.
+ Beschränkungen bei -r in Verbindung mit 5.1 erwähnt.

soundtouch
- Qualität > OTA und Beschränkung auf 2ch eingefügt.

shibatch
- Alternative Schreibweise -ssrc() eingefügt.
+ Hinweis auf AAC-Downsampling nach bsn verschoben.

Azid
- Normalisierung: 2-Pass erwähnt.
- Alternative Schreibweisen bei -s eingefügt.

Vorbis
- Quali -1 erwähnt.
- "Echtes VBR" präzisiert.

Lame
+ CBR-Bitraten 8 und 16 kbit ergänzt.
+ ABR-Raten: Minimum (77 kbit für v3.90, 72 für v3.96) und Maximum (320 kbit) korrigiert.
+ Schalter -a entfernt, da für BeSweet unnötig (-m m geht immer).
+ Deutlicher gesagt, dass -m nur zum Monodownmix verwendet werden sollte.

bsn
+ Eingefügt: Auto-Downsampling auf 44,1 kHz nur bei Verwendung von -config.

ac3enc
- Hinweis auf mögl. Probleme mit ac3enc
- Normalisierung nur über Azid möglich.

In den letzten Tagen habe ich noch ein wenig getestet, v.a. was AC3 angeht. Wie gesagt, mit Normalisierung über Azid passt die Lautstärke. Ich habe mich auch an einem ABX-Test versucht (5.1 448 kbit/s und 5.1 256 kbit/s), der allerdings nur die FL- und FR-Kanäle einbezieht. Mehr kommt halt am Kopfhörer nicht an. Ergebnis war 4/10, bestens geraten.
Ich erlaube mir mal, ac3enc als weitgehend unbedenklich zu bezeichnen.

Nach abschließend ein bisschen Kosmetik-, Rechtschreib-, Grammatik-, Stilkorrekturen ist die Referenz jetzt fertig.

BeSweet-Kommandozeilenreferenz 15.01.2005 Final

Im Zug der englischen Version gibts ein Update (Link im ersten Posting).

- Klarere Beschreibung von DNR.
- Kleinigkeiten bei der Formatierung behoben.
- Einschränkungen für HE-AAC entfernt (bsn.dll erlaubt HE egal welche Bitrate)
- Beschreibung von -lame( --resample ) korrigiert.