Oder willst du 16 bit FLAC zu YouTube hochladen?
Des sag ich doch die ganze Zeit :zunge:
Jap genau das mache ich so.
Ok also 24bit Aufnahme -> 16bit FLAC -> Youtube
= besser
als
16bit Aufnahme -> 16bit FLAC -> Youtube 
Wenn dem so ist, werd ich das bei der nächsten Aufnahme dann so mal probieren 
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.
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.
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.
Ist auf jeden Fall sehr interessant zu wissen, das es kein Verlust gibt, wenn man 24bit auf 16bit runterrechnet (also bezogen im Vergleich zu direkt in 16bit aufgenommen). Das war mir jetzt echt total neu.
Dann sag ich mal Dankeschön =)
Danke dir.
Also ist es qualitativ sinnvoller in 32bit Float aufzunehmen und später auf 16bit runterzurechnen, statt schon in 16bit aufzunehmen?
Ok da kommt mir dann aber noch eine weitere Frage auf 
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.
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.
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.
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.
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:
[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=44100Sprich er encodiert sie dann auf 24bit 
Lasse ich SSRC weg, passiert das nicht.
Es passiert mit WAVSource als auch mit FFAudioSource..
30fps ist nunmal Maximum.
Das heißt nichts weiter, als das User die über eine starke Internetleitung verfügen, können sich solche Bitraten anschauen.
Das hat nichts damit zu tun das Partner bessere Encodes von denen erhalten. Das hast du leider falsch verstanden.
Außerdem kenn ich genug Leute die Partner sind und vorher nicht Partner waren und es hat sich bezüglich Qualität rein gar nichts geändert.
Insbesondere eine Person aus dem Lets Play Forum wäre da erwähnenswert, die hat nämlich vor kurzem erst Partnerschaft und an der Videoqualität hat sich rein gar nichts verbessert.
Und davon macht Youtube auch keine Aussage. Du hast das ein bisschen falsch verstanden.
Vllt variable FPS Rate, oder isses wirklich exakt 25.000 bei jedem?
MeGUI benutzt auch AssumeFPS.
Framerate maximum von Youtube ist 30.
Mit 30 nehm ich meine Videos auf und encodier sie auch in 30.
Und klar vom Quellmaterial vs Youtubes Encode ist natürlich ein deutlicher Unterschied zu sehen auch auf "Original", falls du das meinst. Ich meintes halt so, das ob ich nun verlustlos hochlade oder CRF 19, das man da augenmäßig bei Youtubes Encode kein Unterschied mehr sieht, weil halt der Verlust deren hohen Quantizer mehr ins Gewicht fällt, als CRF 19 Quelle vs Lossless Quelle.
Aber denoisen&smoothen meinste wirklich macht Sinn, wenn ich gestochen scharfes Spielevideomaterial habe was ich in CRF 19 encodier?
130 Mbit/s, Codec spielt nicht wirklich eine Rolle bei der Datenrate.
Die Datei ist euch zu gross? MeGui 3pass.
Was ein Unsinn...
Man muss lediglich drauf achten, das man möglichst hohe Qualität hochlädt, so das nach deren Encodes möglichst viel über bleibt.
Ist doch hier nicht anders als wenn man einen eigenen Encode doppelt encodieren würde.
Zwischen einer verlustlos hochgeladenen Aufnahme und CRF 19 ist der Unterschied auch auf "Original" so dermaßen marginal, das es nicht vom bloßen Auge erkennbar ist. Dafür ist deren Quantizer pro Encode zu hoch, als das man da eine Differenz bemerken würde.
Nein erlaubt es nicht.
Außerdem benutzt Youtube nicht mal Bitratenencoding.
Woher hast du diese Information?
Nicht mal freddiew oder Gronkh haben bessere Videoqualität. Absolut gar nicht.
Youtube encodiert einfach nach Lust und Laune, du wirst sozusagen bei youtube eingestuft, dein Content wird eingestuft, du als User wirst eingestuft.
Wenn du gute Qualitative Videos uploaden willst musst du Youtube Partner werden.
Absoluter Schwachsinn.
Ich vermute das Youtube mit Constant Quantizer encodiert. CRF auf jeden Fall nicht, weil die Qualität bei komplexen Stellen schlechter ist, als bei inkomplexen. Bitrate auch auf keinen Fall, da die Dateigrößen sich CRF und CQ typisch nach der Komplexität anpassen. Auf keinen Fall fixe Bitrate.
Vergesst bitte nicht, das Youtube ihre Encodings nicht nur in unterschiedlichen Auflösungen macht, sondern die gesamte Videoqualität ist auf den höheren Encodings BESSER.
Sprich der 1080p Encode ist mit viel besserem Quantizer encodiert, als der 720p encode. Unterhalb 720p wird auch die Audiobitrate reduziert.
Ein CRF 25 1080p Video sieht Youtubes 1080p Encode noch immer besser aus, als ein CRF 21 720p Video auf Youtube's 720p Encode.
Die höchste Videoqualität erhältst du mit >1080p.
Meine Videos sind in 2048x1152 und da bietet Youtube nochn weiteren Encode namens "Original" Das steht für originale Auflösung, ergo 2048x1152 und bei dem Encode wird nochmals ein sehr viel besserer Quantizer benutzt.
Hier auch mein Kanal:
http://www.youtube.com/user/Fleshshredder
Ich encodier mit MeGUI mit x264 @ CRF 19, 2048x1152, 30fps, preset slow.
Naja es wäre halt bequemer, wenn Avisynth sowas hätte, dann bräuchte er nicht doppelt encodieren (Zeitersparnis).
@ De-M-oN:
Nur ein feineres Chroma-Subsampling macht noch keinen anderen "Farbraum"; ob 4:2:0 oder 4:2:2 oder 4:4:4 – YUV ist YUV (statt RGB als wirklich "anderer Farbraum").
Ich hatte mal 'ne 13 GB RGB verlustfrei komprimierte Datei hochgeladen und hat Youtube anstandslos encodiert.
@ sneaker2:
Ich habe mal feststellen müssen, dass der YouTube-Konverter insbesondere nur mäßige AVC-Komplexität unterstützt, also keinesfalls mit B-Frames und Referenz-Frames übertreiben. Insofern ist "brutale Dateigrößen-Minimierung" also nicht sinnvoll.
Jemand anders den ich im ICQ hab, hat spaßeshalber mal Placebo Preset verwendet (mit subme 11, und noch ausgeweitet mit me range 64^^), 2048x1152 Auflösung und hat youtube anstandslos ohne Fehler encodiert.
Wichtig ist nur, das keine Kopfdatenkompression verwendet wird. Das mag Youtube oftmals gar nicht.
Andere Farbräume gehen, aber 10bit bezweifel ich auch ein bisschen.
Die Qualitätsstufen am Player sind halt in der Tat keine bloße Auflösungseinstellung, sondern auf höherer Stufe gibt Youtube auch deutlich mehr Qualität. Audio als auch Video.
Man kann sogar eine Hochskalierung mit Lanczos4 in Erwägung ziehen, auf zb 2048x1152 (ich brauchs nicht, mein Monitor kann eh 2048x1152 nativ und lade daher auch 2048x1152 Videos auf Youtube) und man wird das deutlich bessere Bild auf Youtube haben. Zum einen ist dann "Original" verfügbar, wo Youtube das Video in der originalen Auflösung von 2048x1152 abspielt und da gibt Youtube auch nochmal deutlichst mehr Videoqualität als bei 1080p. Und auch die kleineren Qualitätsstufen sehen natürlich hübscher aus, wenn man besseres Quellmaterial hochgeladen hat.
