MeGUI encodiert 16bit WAV zu 24bit FLAC wenn SSRC

    Hab da ein kleines Problem mit MeGUI :(

    Ich habe von jemandem eine WAV bekommen und für ihn bearbeitet und möchte die WAV, die in 48 khz, 16bit vorliegt mit dem SSRC Filter auf 44100 bringen und als FLAC encodieren.

    Immer wenn ich aber SSRC einsetze, gibt MeGUI das an den FLAC Encoder:

    Code
    [Information] [07.11.2012 13:19:18] Commandline: C:\Program Files (x86)\MeGUI\tools\flac\flac.exe --force --force-raw-format --endian=little --sign=signed -8 - -o "D:\XVideos\recettear 2012-11-06 12-12-59-639 st0_edit.flac" --channels=2 --bps=24 --sample-rate=44100

    Sprich er encodiert sie dann auf 24bit :huh:

    Lasse ich SSRC weg, passiert das nicht.

    Es passiert mit WAVSource als auch mit FFAudioSource..

    Ist das evtl. beabsichtigt, da der Filter intern mit höherer Genauigkeit arbeitet und es so besser ist, bei 24 bit zu bleiben? Genau beantworten kann das wohl nur Zathor.
    Bis dahin wohl am besten Goldwingfahrers Rat befolgen und es mit einer anderen Software machen.

    Zitat

    Ist das evtl. beabsichtigt, da der Filter intern mit höherer Genauigkeit arbeitet


    ....grübel....in der Regel braucht man Wav in 24 oder 32 Bit wenn noch gefiltert werden muss,zum Bsp.mit Wavelab,Samplitude X Pro Suite oder Nuendo...schlussendlich muss das Wav aber doch wieder auf 16 bit gedithert werden.

    MeGui setze ich nicht ein...habe ich da was verpasst.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

    Also bei mir haut SSRC() 32 bit Float raus, auch wenn 16 bit reinkommt.
    Warum das bei MeGUI dann auf 24 bps geht: keine Ahnung. Vielleicht setzt es ein ConvertAudioTo24bit() hinten dran?
    Also entweder schauen, ob Zathor was ändert, ResampleAudio() nehmen, ConvertAudioTo16bit() dahintersetzen, oder halt was anderes als MeGUI.

    Oder nimmt MeGUI dafür eac3to? Das gibt nämlich 24 bit mit SSRC bei mir aus.

    Einmal editiert, zuletzt von sneaker2 (7. November 2012 um 16:43)

    Zitat

    Ist das evtl. beabsichtigt, da der Filter intern mit höherer Genauigkeit arbeitet und es so besser ist, bei 24 bit zu bleiben? Genau beantworten kann das wohl nur Zathor.

    Gibt für mich aber nicht so wirklich Sinn, weil die Eingangsdatei ja bereits in 16bit vorliegt.

    Zitat

    Warum das bei MeGUI dann auf 24 bps geht: keine Ahnung. Vielleicht setzt es ein ConvertAudioTo24bit() hinten dran?

    Nope.

    Aber wenn du meine gepostete Commandline oben siehst, gibt MeGUI 24bit an den FLAC Encoder als Option, statt 16bit. Also er weist dem FLAC Encoder somit an in 24bit zu encoden. Daher denke ich auch, das dies der einzige Fehler ist.

    Zitat

    Also bei mir haut SSRC() 32 bit Float raus, auch wenn 16 bit reinkommt.

    Der SSRC Filter wandelt also die Bittiefe in 32bit erstmal um? Hmm. Ist das nicht negativ, wenn die Bittiefe hin und her gewandelt wird?
    Ich wollte halt eig. SSRC nehmen, da der ja besser sein soll als ResampleAudio.

    Letztendlich ist Resamplen verlustbehaftet. Und für verlustbehaftete Verfahren gilt eigentlich immer, daß man sie mit der höchstmöglichen Genauigkeiten durchführen sollte. Und 32 bit sowie 24 bit sind nun mal genauer als 16 bit. Häufig wird intern genauer gearbeitet und dann später gerundet (schlecht) oder Dithering (gut) angewandt. Das ist nicht schlimm bzw. gewollt. Wenn er von sich aus nicht auf 16 bit dithered, muß man dies halt manuell tun.
    Was genau MeGUI jetzt warum macht, weiß ich nicht.

    Mit eac3to:
    eac3to input.wav output.wav -resampleTo44100 -down16
    bzw. gleich auf FLAC:
    eac3to input.wav output.flac -resampleTo44100 -down16

    Ok da kommt mir dann aber noch eine weitere Frage auf :D

    Ich mache Lets Play Videos für Youtube und habe als Mikrofon das Rode NT2-A und als Audiointerface die PreSonus Audiobox 22 VSL. Das Audiointerface kann bis zu 24bit, 96khz aufnehmen.

    Ich habe mit DXTory immer in 44100,16bit aufgenommen.

    Würdes also Sinn machen in 24bit aufzunehmen, obwohl ich nachher eh auf 16bit muss? Denn Samplerate hab ich auch nicht höher als 44100, da ich später eh auf 44100 muss und dachte mir es wäre einfach das sinnvollste dann auch direkt in 44100 aufzunehmen um eine Sampleratekonvertierung zu vermeiden. Das ist doch richtig oder? Falls ja, das dachte ich mir dann nämlich auch bei der Bittiefe, das es da genauso ist.

    Zitat von De-M-oN

    Der SSRC Filter wandelt also die Bittiefe in 32bit erstmal um? Hmm. Ist das nicht negativ, wenn die Bittiefe hin und her gewandelt wird?

    32-bit IEEE float hat immer eine Mantisse von 24 bit Genauigkeit, in leisen wie in lauten Szenen.

    16-bit integer hat maximal 16 bit Genauigkeit in den lautesten Szenen. In leisen Szenen entsprechend weniger.

    Schlechter wird es durch die Konvertierung von 16-bit integer nach 32-bit float also mit Sicherheit nicht. Und dann wird mit normalisierten Werten (-1,0 .. +1,0) gerechnet, das ist sowohl numerisch einfacher als auch sicherer, weil eventuelle Übersteuerungen noch zuverlässig zwischengespeichert und falls nötig kompensiert werden können.

    BeSweet arbeitet genauso intern mit Fließkommasamples. Viele komprimierte Audioformate (z.B. Dolby Digital AC3) arbeiten intern ohnehin mit Fließkommaparametern, da kann der verwendete Decoder schon mal auf das Herunterrechnen auf 16-bit Integer verzichten.

    Die Aufnahme per Mikrofon mit höherer Auflösung kann durchaus auch nützlich sein, denn um Übersteuerungen zu vermeiden, wird der Aufnahmepegel ja gern relativ pessimistisch niedrig gewählt, und wenn man sich da schon auf 16-bit integer beschränkt, dann bleiben bei geringerer Lautstärke schon mal nur noch 10-14 bit Genauigkeit übrig. Höhere Frequenzen würde ich aber nicht grundsätzlich empfehlen, das dürfte selten wirklich Nutzfrequenzen bringen.

    Professionelle Tonstudios arbeiten tatsächlich mit Float-Samples. Bei der Aufnahme reicht aber 24-bit Integer, echte Float-Samples dürfte das Soundsystem wohl nicht nativ unterstützen. Beachte aber, dass nicht jeder Sample-Editor oder Encoder gleich gut mit jedem Sampleformat umgehen kann (z.B. hat WAV mit Float-Samples das Format 3, mit Integer-Samples aber Format 1; CoolEdit/Audition hat sogar ein nicht standardisiertes eigenes Festkomma-Format).

    Äh, doch ... beim Herunterrechnen von 24 auf 16 bit kann es Verluste geben. Bisher hatten wir nur über das Hochrechnen von 16 auf 24 bit oder auf Float gesprochen.

    Wie erheblich der Verlust ist, hängt von einigen Faktoren ab. Die Aussteuerung ist ein wesentlicher Faktor, Normalisierung spielt da mit hinein. Dithering und Noise Shaping verbessern die durchschnittliche Dynamik durch statistische Verteilung des Fehlers.

    Aber was ist dann zum Aufnehmen nun sinnvoller?

    in 16bit aufnehmen, auf 16bit bleiben.
    oder
    in 24bit aufnehmen (wo du ja sagst das dann mehr Aufnahmequalität einfließt), und auf 16bit gehen

    ?

    Auf 16bit muss ich nachher sowieso gehen. Mach ich es nicht, macht Youtube es mit ihrem AAC encode.

    Daher die Frage: Welcher Weg ist sinnvoller? :)

    Nach deinen Erklärungen vermute ich ja daher das 24bit -> 16bit sinnvoller ist, da ich daher mal vermute das die bessere Qualität der Aufnahme mit 24bit, bei 16bit mehr über bleibt, als eine direkte 16bit Aufnahme.
    Daher frag ich einfach mal.

    Sicherlich ist die Aufnahme in 24 bit und die Verarbeitung in 24 bit grundsätzlich besser, weil dann während der Verarbeitung möglichst lange noch das Optimum an Qualität erhalten bleibt. Bleib bei höheren Auflösungen, solange es möglich ist. Wahrscheinlich kannst du auch 24-bit-WAV in AAC encodieren (wenn nicht mit bestimmten GUIs, dann vielleicht mit dem CLI-Encoder direkt). Und wenn nicht, ist das Herunterrechnen der finalen Abmischung in 16 bit, erst vor der Konvertierung, die zweitbeste Lösung.

    Zitat von LigH

    Wahrscheinlich kannst du auch 24-bit-WAV in AAC encodieren


    Eine 24bit AAC wird mir MeGUI sicherlich machen können. Aber was das betrifft, gehts ja nicht um mich, sondern Youtube. Und Youtube encodiert auf 16bit.
    Von daher kann ich meinen finalen Encode (was FLAC ist) auch gleich in 16bit machen. Mir gings halt nur um die Frage von oben. Was eben sinnvoller ist. 24bit aufnehmen, encode 16bit, oder aufnehmen 16bit, encode 16bit. Aber wenn ich dich richtig verstehe ist es also 24bit -> 16bit in dem Fall besser.

    Wenn YouTube was herunterkonvertiert, ist sowieso egal, ob es mal ursprünglich 16 oder 24 bit hatte, es kann nur schlechter werden. Und das in ganz anderen Größenordnungen als 16, 15 oder nur 14 bit, da gehen vor allem Frequenzanteile verloren, da ändert sich der Klang insgesamt. Ob wenigstens bei HD-Video die Tonspuren auch mal im Original erhalten bleiben, könnte ich auch nicht bestätigen. Aber es gibt ab und zu Videos mit deutlich besseren Tonspuren, interessanterweise meist die mit Standbild-Video.

    Bei 720p und höher encodiert Youtube in AAC 44,1 khz, 16bit, 192 kbit/s (VBR)

    So schlimm find ich das jetzt nicht. Das die nicht in FLAC encodieren sollte ja klar sein ^^.

    Wenn man FLAC im Video hat isses ja dann auch Lossless -> Lossy und 192er AAC find ich jetzt nicht sooo schlimm.

    Sag mir am besten, was einfach die bessere Methode ist. 16bit aufnehmen -> encode 16bit, oder 24bit aufnehmen -> 16bit encode.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden