ConvoFS (Convolving File System)

[Fortepianus]

Hallo Uli,

ja, das ist mir soweit klar, aber gut, dass Du nochmal beschreibst, was Dithering ist. Das ist hilfreich für diejenigen, denen das nicht ganz so klar ist. Bei ConvoFS ist das Problem, dass es diverse an- und abwählbare Prozesse gibt, an deren Ende aber nicht zwangsweise gedithert wird. Ich nutze beim Musikhören in jedem Fall die online-MS-Konvertierung von ConvoFS. Am Ende dieses Prozessschrittes erfolgt aber kein Dithering. Vergleiche ich mit offline-Ergebnissen von acourateNAS oder foobar, klingt die MS-Konvertierung von ConvoFS ähnlich wie die offline-Konvertierung, wenn Dithering abgeschaltet ist. Schalte ich es ein, ist offline online überlegen. Falte ich online mit ConvoFS (mit acourate erstellte FIR-Filter), erfolgt ebenfalls kein Dithering, das ist abgeschaltet (weil fehlerhaft in bruteFIR, wenn ich das richtig verstanden habe). Auch da klingt offline ähnlich ohne Dithering und mit besser. Ebenso ist es, wenn ich Loco von Frank einschalte. ConvoFS dithert erst mit SOX, also wenn am Ende Upsampling erfolgt. Das läuft aber nur in der reinen Linux-Variante, nicht in der NAS-Version für die Synology, die ich verwende. Deshalb erfolgt in der von mir verwendeten Version gar kein Dithering. Ich sollte also meinen Wunsch präzisieren: Egal, welcher Prozess angewählt ist in ConvoFS, ob MS, Loco, FIR-Filter oder Upsampling, es sollte am Ende immer gedithert werden können, also ein Prozessschritt am Ende eingefügt werden, den man meinetwegen mit einem Häkchen an- oder abwählen kann und der nur das Dithering am Ende vor der Konvertierung in 24bit Ganzzahlen macht. Interessant ist, dass man den Unterschied gut hören kann auch bei 24bit (ConvoFS verwendet immer 24bit).

Viele Grüße
Gert

[frankl]

Hallo Dither-Fans,

also, ich würde gerne mal ein 24-Bit Stück hören, das mit und ohne Dithering unterschiedlich klingt. Ich habe da mal ausführliche Tests gemacht und normal ausgesteuerte Musik mit 64 Bit floating-point Samples bei verschiedenen Bittiefen abgeschnitten und gedithert. Bei sehr gut produzierter Musik habe ich mir eingebildet, bei 19 oder 20 Bit einen kleinen Unterschied zu hören - wohl nicht blindtesttauglich. Seitdem bin ich davon ausgegangen, dass bei 24 Bit wenigstens die untersten 3 oder 4 nur noch zufälliges Rauschen sind und kein Nutzsignal enthalten (Dithern ersetzt das dann nur durch anderes zufälliges Rauschen).

   sys("sox -V1 --ignore-length -q -D -t flac $file -t raw -c $chans -b 24 -e signed-integer - trim =${leftprecut}s  =${rightprecut}s $pad $dither remix @remix_str | $lock /bin/sh -c \"$fir\" | sox --ignore-length -q -D -t raw -c $chans -b 24 -e signed-integer -r $rate - -b $postbits -t wav $flif trim =${leftpostcut}s =${rightpostcut}s rate -v $postrate");


Hm, diese Zeile ist in der Tat im Code von ConvoFS zu finden. Da wird eine flac-Datei gelesen und in PCM-Rohdaten mit 24 Bit Integers verwandelt (genauer, ein ausgeschnittenes Stück der Datei), dies wird dann zum Falten nach brutefir geschickt (versteckt sich in '$fir'), heraus kommen wieder Samples als 24 Bit Integers.

Das 'dither' kommt nur bei der ersten Verwandlung in 24-Bit Daten zum Einsatz. An der Stelle macht das aber gar keinen Sinn (außer, wenn die Eingangsdatei eine höhere Bittiefe hätte). Beispiel, in dem 'data.flac' eine 44.1/16 flac-Datei ist:

sox data.flac -t raw d.raw
sox data.flac -t raw dd.raw dither
cmp d.raw dd.raw    # dies zeigt, dass beide Dateien identisch sind
sox data.flac -t raw -b 24 d24.raw
sox data.flac -t raw -b 24 dd24.raw dither
cmp d24.raw dd24.raw
sox -V data.flac -t raw -b 24 dd24.raw dither
[...  viel Output ...]
sox INFO dither: has no effect in this configuration
[... noch mehr ...]


Das 'dither' würde in der obigen Beispielzeile aus ConvoFS auch im hinteren Aufruf von 'sox' nach dem Convolver keinen Sinn haben, denn da hat 'brutefir' schon ohne dithering die Samples auf 24 Bit Tiefe gestutzt und jede mögliche Information in weiteren Bits ist unwiederbringlich verloren - es ist es zu spät zum Dithern. (In diesem alten Beitrag wurde versucht, das etwas genauer zu erklären.)

Das bessere Vorgehen ist: Zuerst die Ausgangsdatei in Rohdaten mit floating-point Samples (mindestens 32 Bit, ich benutze immer 64 Bit) zu verwandeln, diese durch den Convolver und welche Filter auf immer schicken, der das Ergebnis auch in floating-point Samples mit der gleichen Auflösung ausgibt. Dann ganz zum Schluss werden die Bits zurechtgestutzt und wieder in Integer verwandelt, dies ist die Stelle, wo Dithering (vielleicht) sinnvoll ist.

Viele Grüße,
Frank

[Buschel]

Hallo zusammen,

wie von Uli und Frank beschrieben macht Dithering nur Sinn, wenn von einer hohen Rechenauflösung (typisch float/double) auf eine geringere (typisch 16-24 Bit Integer) gewechselt wird. Und das durchaus bei jedem Schritt, bei dem diese Wandlung geschieht. Aber: Eine sauber implementierte Signalverarbeitungskette macht diesen Schritt nur ein einziges Mal, am Ende. Ich denke es macht daher Sinn, zunächst zu reviewen wie ConvoFS nun wirklich arbeitet. Wenn z.B. M/S und LoCo mit float-in und float-out arbeiten, ist Dithering hier unnötig und sogar kontraproduktiv (der Signalrauschabstand wird verringert). Wenn die M/S- und LoCo-Schritte mit integer-out arbeiten, sollte nicht Dihtering hinzugefügt werden, sondern die Ausgabe auf float umgebaut werden. Erst der abschließende sox-Schritt sollte von float auf Integer umrechnen und dabei Dither anwenden.

Wenn MS und LoCo über brutefir umgesetzt sind (wovon ich ausgehe), rechnet brutefir das üblicherweise komplett in float. Hier erwarte ich deswegen gar kein Problem. Eventuell fehlt wirklich der abschließende Ditheringschritt. Zur derzeit gewählten Implementierung kann Michael wohl am besten Auskunft geben.

Grüße,
Andree

[h0e]

Hallo zusammen,

wieder mal schön zu sehen, wie hier "Grundlagenforschung" betrieben wird.
Frank, würdest Du Michael mal anschreiben und ihm die "richtigen" Fragen stellen?
Ich würde mich ungern dazwischenschalten, da ich nicht so tief in der Materie bin.
Das wäre toll.

Grüsse Jürgen

[Daihedz]

... Frank, würdest Du Michael mal anschreiben und ihm die "richtigen" Fragen stellen? ...

Dithering ist wie in der oben im Skript wiedergegebenen Weise in Version 3.0 mittels Sox (an der falschen Stelle) aktiviert. Denn die Variable ist Eingangs des Perl-Skripts mittels
dither='dither'
initialisiert und deklariert.

Vielleicht gibt es schon mal die richtigen Antworten her, wenn die Ausgabe von
$ man sox
gelesen wird:

dither [-S|-s|-f filter] [-a] [-p precision]

Apply dithering to the audio. Dithering deliberately adds a small amount of noise to the signal in order to mask audible quantization effects that can occur if the output sample size is less than 24 bits. With no options, this effect will add triangular (TPDF) white noise. Noise-shaping (only for certain sample rates) can be selected with -s. With the -f option, it is possible to select a particular noise-shaping filter from the following list: lipshitz, f-weighted, modified-e-weighted, improved-e-weighted, gesemann, shibata, low-shibata, high-shibata. Note that most filter types are available only with 44100Hz sample rate. The filter types are distinguished by the following properties: audibility of noise, level of (inaudible, but in some circumstances, otherwise problematic) shaped high frequency noise, and processing speed.

See http://sox.sourceforge.net/SoX/NoiseShaping for graphs of the different noise-shaping curves.

The -S option selects a slightly `sloped' TPDF, biased towards higher frequencies. It can be used at any sampling rate but below ≈22k, plain TPDF is probably better, and above ≈ 37k, noise-shaping (if available) is probably better.

The -a option enables a mode where dithering (and noise-shaping if applicable) are automatically enabled only when needed. The most likely use for this is when applying fade in or out to an already dithered file, so that the redithering applies only to the faded portions. However, auto dithering is not fool-proof, so the fades should be carefully checked for any noise modulation; if this occurs, then either re-dither the whole file, or use trim, fade, and concatencate.

The -p option allows overriding the target precision

If the SoX global option -R option is not given, then the pseudo-random number generator used to generate the white noise will be `reseeded', i.e. the generated noise will be different between invocations.

This effect should not be followed by any other effect that affects the audio.

See also the `Dithering' section above.

sowie

Dithering

Dithering is a technique used to maximise the dynamic range of audio stored at a particular bit-depth. Any distortion introduced by quantisation is decorrelated by adding a small amount of white noise to the signal. In most cases, SoX can determine whether the selected processing requires dither and will add it during output formatting if appropriate.

Specifically, by default, SoX automatically adds TPDF dither when the output bit-depth is less than 24 and any of the following are true:
· bit-depth reduction has been specified explicitly using a command-line option
· the output file format supports only bit-depths lower than that of the input file format
· an effect has increased effective bit-depth within the internal processing chain

For example, adjusting volume with vol 0.25 requires two additional bits in which to losslessly store its results (since 0.25 decimal equals 0.01 binary). So if the input file bit-depth is 16, then SoX's internal representation will utilise 18 bits after processing this volume change. In order to store the output at the same depth as the input, dithering is used to remove the additional bits.

Use the -V option to see what processing SoX has automatically added. The -D option may be given to override automatic dithering. To invoke dithering manually (e.g. to select a noise-shaping curve), see the dither effect.

Diese Man ist doch schon mal ein sehr schönes Tutorial zum Thema Dithering, welche denn auch manche Frage zu Dithering im Allgemeinen und auch hier im Faden spezifisch dessen Verwendung, resp. Auswirkung in ConvoFS unter der gegebenen aktuellen Implementation schon mal beantwortet.

Lesend-lernende Grüsse
Simon

[Fortepianus]

Liebe Online-Falter,

habe mit Michael regen Mailkontakt wegen Dithering, und er bat mich, seine Alpha-Version 3.0 zu installieren, damit er dann dort die Dither-Option mit Schalter ausprobieren kann. Auf 3.0 hatte ich auf sein Anraten vor 2-3 Monaten schon mal gewechselt, hatte damals aber das Problem, dass der Minimserver nicht mehr lief (der Minimserver verabschiedet sich und das Icon von Minimwatch wird rot). Nun hat er eine neue Version 3.0 und eine neue Base gemacht, ich habe wieder gewechselt und ich habe das red-icon-Problem immer noch. Ein Problem scheint mir aber schon die neue ConvoFS-base-5.00x zu sein - auch die ConvoFS-Version 2.3.2, die nur mit Base 5.00x läuft, hat dieses rote-Icon-Problem. Hat einer von Euch die eigentlich offiziell freigegebene Version 2.3.2 mit Base 5.006 auf einer Synology am Laufen, ohne dass der Minimserver abstürzt? Das Zurückwechseln auf eine frühere Version ist immer recht zeitaufwändig, weil man erstmal alles komplett deinstallieren muss (ConvoFS und Base) auf der NAS, weil sonst die Installation nicht geht (zu installierende Version älter als vorhandene etc.). Dann sind alle Filter weg und man fängt von vorne an.

Viele Grüße
Gert

[h0e]

Hallo Gert,

rotes Icon bei Minim bedeutet normal, dass er nicht läuft.
Erste Frage, gibt es ein ConvoFS Mount Verzeichnis, in dem Files liegen?
Wenn ja, was sagt das Log von Minim?

Grüsse Jürgen

[Fortepianus]

Hallo Jürgen,

rotes Icon bei Minim bedeutet normal, dass er nicht läuft.
Erste Frage, gibt es ein ConvoFS Mount Verzeichnis, in dem Files liegen?

ja klar, das war mein erster Check. Die flacs im virtuellen Verzeichnis kann ich auch vom Windowsrechner aus abspielen.

Wenn ja, was sagt das Log von Minim?

Der Absturz ist dort interessanterweise gar nicht dokumentiert - im Log-Filessteht nur alles Paletti. Fährt man aber mit der Maus über das rote Icon, steht da als Text:

"Minimserver[Diskstation16TB]: exception while processing action request: java.lang.IndexOutOfBoundsException: Index: 18801, Size" und den Rest kann man nicht mehr sehen, weil Text zu lang.

Minim startet ganz normal und liefert nach dem Rescan (gelbes Icon) brav ein grünes, aber sobald ich dann Kazoo starte und auf den Minimserver zugreife, zack, ist es rot und der Minimserver hängt im Busch. Kazoo zeigt dann gar nichts mehr an aus Minim - klar, das hängt ja auch.

Das ist bei mir zuverlässig bei ConvoFS 2.3.2 mit Base 5.006 ebenso wie bei 3.0.0 mit Base 5.004 oder 5.006. Es ist auch egal, von welchem Rechner oder iPad aus ich auf den Minim zugreife oder mit welchem Programm (Control Point). NAS, auf der Minim und ConvoFS laufen, ist die Synology DS716+II. Darauf sind folgende Pakete installiert:



Man sieht hier im Bild wieder ConvoFS 2.3.1 mit Base 4.003, denn das ist die letzte Version, die einwandfrei läuft bei mir. Läuft bei Dir denn 3.0.0 oder auch 2.3.2 unter Base 5.006?

Viele Grüße
Gert

[h0e]

Hallo Gert,

ich hatte wg. eines Bugs, der Neuinstallationen verhinderte keine Base 5.xxx und Convo 3.alpha installieren können.
Das führte dazu, dass das Mountverzeichnis gar nicht erst gefüllt wurde.
Michael hatte deshalb die 5.6 gemacht, die habe ich noch nicht versucht.
Offensichtlich hat er noch nicht alle Problem gelöst.

Grüsse Jürgen