Beiträge von Sagaras

Du kannst immer nur ein Verfahren verwenden. Entweder CRF oder QP oder ABR bei x264.

CRF -> konstante Qualität
QP -> konstanter Quantizer
ABR -> durschnittliche Bitrate

Und ABR lässt sich noch in 1pass, 2pass und sogar 3pass nutzen.

Zitat von Ancrion

Weil bei qp steht ja I.d.R. sollten wir ein CRF-Encoding bevorzugen

Stimmt ja auch. In der Regel verwendet man kein QP bei einer normalen Lossy Encodierung, sondern nutzt das CRF Verfahren, weil das Effektiver ist.

Du möchtest aber Lossless mit x264 aufnehmen und da bringt einen CRF nix. Das geht nur mit einem konstanten Quantizer mit dem Wert 0.

CRF Erklärt:
http://encodingwissen.de/codec…#crf-qualitatsfaktor-star

QP Erklärt:
http://encodingwissen.de/codec…enz/#qp-p-frame-quantizer

CRF kann kein Lossless erreichen, da es nur ungefähr den durchschnittlichen Quantizer entspricht.
Der Quantizer muss aber exakt 0 sein, damit Lossless möglich ist.

Den CRF nimmt man wenn man Qualitativ encodieren will ohne festen Dateigrößenziel.

Zitat von Ancrion

Aber mit dem normalen x264 in Open Brodcaster Studio nehm ich nicht lossless auf, oder?

Du musst auch in der Benutzerdefinierten Command-Line (x264 Optionen heißt es in OBS) qp=0 angeben für x264.

qp=0 steht für den Quantizer der P-Frames. Steht dieser auf 0 aktiviert man bei x264 den Lossless Modus.
Und dann ist es absolut egal welche Bitrate man einstellt. Solange qp=0 als Angabe gemacht wurde sind sämtliche Bitraten Angaben nicht relavant mehr. Dann kannste die Bitrate auch auf 2 oder 1 oder 0 stellen, du bekommst immer max. Bitrate.

Wieviel Bitrate das ist richtet sich nach den Frameinhalten. Die komplexen Frames bekommen halt enorm viel Bitrate und die inkomplexen Frames halt weniger. So das das Video eine VBR am Ende besitzt, bei dem jeder Frame soviel Bitrate bekommt das die bpp am Ende die des gewählten Farbraumes erreicht.

Sprich bei YV12 wirst du max. 12bpp erreichen, bei YUY2/YV16 wirst du max. 16bpp erreichen und bei YV24 wirst du halt 24bpp erhalten.

Und RGB kann x264 nicht. Also wenn du RGB eingestellt haben solltest, dann wird OBS bei der Verwendung von x264, NVenc, etc. auf YV12 umstellen. Einfach weil h264 im Allgemeinen kein RGB kann.

Die RGB Einstellung in OBS ist relevant für die FFmpeg Nutzung, wenn man z.B. mit UTVideo oder Lagarith aufnehmen will.

Und dann sehr wichtig:
Bei RGB sind Farbbereich und Farbmatrix nicht relevant, da RGB dies nicht besitzt. RGB ist immer Vollbereich und besitzt 3 festgelegte Farben. Daher braucht es keine Farbmatrix.

Bei YUV ist das anderes. Um YUV zu berechnen sind Farbbereich als auch Farbmatrix wichtig.

Wem das genauer interessiert, gibt es im Gleitz Forum einen ausführlichen Thread dazu: http://forum.gleitz.info/showt…rmeln-f%FCr-Koeffizienten)

Sofern du kein Lossless aufnimmst sind diese von Relevanz, ja. Aber wenn du Lossless aufnimmst über x264 via qp=0 oder via FFmpeg mit UTVideo, spielt die Bitrate keine Rolle.

Bei Lossless wird soviel Bitrate genommen damit es ausreicht um ein 1:1 Verhältnis bei den Frames zu erzielen.

Sprich wenn du in RGB aufnimmst, dann ist das Ergebnis 1:1 dem was du aufgenommen hast.
Die Spiele laufen alle in RGB32

Den Alphakanal braucht man bei der Aufnahme ja nicht wodurch sich ein RGB24 Video ergibt der das gesamte Bild enthält.

Unkomprimiert würde somit ein RGB Frame bei z.B. 640x480 sich folgendermaßen rechen:
640 * 480 * (24 Bit / 8 )= 921600 Bytes = 900 KB

Bei einer Länge von 30min bei 60 FPS sind das dann:
900 KB * (30 * 60)sek * 60 FPS = 97200000 KB = 94921,875 MB = 92,7 GB

Das wäre RGB unkomprimiert. Natürlich nimmste nicht unkomprimiert auf, sondern komprimiert und kommst somit auf einen Wert der Weit unter diesem Ergebnis ist. Nur größer kann dann dein Video mit diesen Angaben nicht werden.

Bei YUV verhält sich das auch so, nur ist bei YUV der U und V Channel limitiert. Sprich der Chroma (Farbanteil).

Unkomprimiert YUV 4:2:0 würde mit 12Bit speichern. 8Bit für Y (Luma), 2Bit jeweils für U und V.

Das macht dann pro Frame:
640 * 480 * (12 Bit / 8 ) = 460800 Bytes = 450 KB

Und für 30min bei 60 FPS sind das dann:
450 KB * (30 * 60)sek * 60 FPS = 48600000 KB = 47460,938 MB = 46,35 GB

Da du das aber auch nicht unkomprimiert aufnimmst, wird das bei einem Verlustfreien Kompression Codec wie UTVideo, MagicYUV, Lagarith, und wie sie alle heißen noch komprimiert. Um wieviel es komprimiert wird hängt von den Frames ab wie gut sie sich komprimieren lassen.

Und das ist Verlustfrei.

Bei einem Verlustbehafteten Codec bzw. Aufnahme nutzt man Bitraten um die Qualität eines Frames zu senken um sie so kleiner zu machen. Das hast du bei einem Lossless Codec nicht.

Ein Lossy Codec braucht eine Bitraten Angabe in welcher Form auch immer. Sei es mit CBR, ABR oder VBR.

Es gibt nur diese 3 Bitraten.
VBR ist eine varable Bitrate. Sie könnte somit jedem Frame eine andere Bitrate und somit jeden Frame unterschiedlich groß machen. Wenn man dies optimal nutzt wie bei dem CRF Verfahren bei x264, dann kann man eine Datei ziemlich klein machen bei optimaler Qualität noch. (Hinweis: Optimal ist hier nicht 1:1, da der Codec ja ein Verlustbehafteter ist.)

CBR stellt mitunter das schlimmste dar. Man gibt eine Bitrate an und diese ändert sich nicht für das gesamte Video. Das heißt das jeder Frame die gleiche Bitrate besitzt. Damit werden unkomplexe Stellen im Video sehr schön dargestellt, aber sobald komplexere Sachen auftauchen, kann es sein das die Bitrate nicht ausreicht und das Bild verschmiert bzw. schmeißt DCT Blöcke.

ABR ist eine Mischung aus beiden. Ziel ist es hier die Bitrate sehr nah an die angegebene Dateigröße zu richten. Je mehr Durchgänge man macht wie z.B. 2pass oder 3pass (2pass reicht in der Regel meist), so kann man sich der gewünschten Dateigröße so weit nähern das die Bitrate für die angegebene Dateigröße optimal ist.

Das sind die 3 Verfahren.
In der Regel rechnet man Bitraten nach dem ABR Prinzip:

Sprich Wieviel Bits pro (Pixel * Frame) sollen vergeben werden?

Wir haben die Pixel und auch die Anzahl der Frames und wir möchten daraus eine Datei mit 400MB erzeugen. Wieviel Bitrate ist notwendig dafür?

Also rechnet man:

400MB * 1024 = 409600 KB
409600 KB / (30 * 60)sek = ~227,6 KByte/sek (KB/s)
227,6 KBytes/s * 8 = 1820 KBit/sek (Kb/s)

Den Weg kann man auch anders herum rechnen.

Hier würde ich z.B. sehen das 400 MB nicht sonderlich ausreicht. Aber für ein 640x480 Video reicht das eigentlich locker

Sprich 1820 Kb/s würde ausreichen für dieses Video.

Jetzt kommt aber das ABER... ich wüsste nicht wie die Qualität am Ende wird, einfach weil es in einem Video unkomplexe und auch komplexe Frames sind. Das heißt die ABR Angabe ist nur ein geschätzter Wert, denn wenn nach VBR encodiert wird trifft dieses Berechnungsergebnis nicht mehr zu. Da diese Berechnung lediglich auf ein CBR Basierendes Video zurückführt. Denn VBR kann man nicht in Vorfeld zu 100% berechnen.

Dann kommt noch der Overhead hinzu + die Dateigröße des Containers + Header und dann müssten man schon 410MB einplanen bei 1820 Kb/s

Und im Grunde wirkt sich das natürlich entsprechend auf die Qualität aus alles. Denn man hat nun nicht mehr volle Bits die man nutzt, sondern gebrochene Bits.

Und die Bit pro Pixel stellen die Qualität dar. Kurz: bpp

Als Vergleich YV12:
unkomprimiert Lossless: 640 * 480 * (12bpp / 8 ) = 460800 Bytes = 450 KB

Um jetzt die Byte für 1 Frame zu bekommen nutzen wir nun die 1820 kb/s und nehmen den Kehrwert von unserer Video FPS. Sprich 1/60 und erhalten somit die Dateigröße für ein Frame des Videos:
1820 kb/s = 1820000b/s * 1/60 = 30333,333333333333333333333333333 Bit * 8 = 242667 Byte = 237 KB

ABR Berechnung: 242667 Bytes / (640 * 480) = 0,789931640625 * 8 = ~6,32 bpp

Und das ist die Hälfte fast. Bei YUV 4:2:0 wäre 12 bpp max. Mit der Bitrate lässt sich dies aber beeinflussen. Die Bitrate ist sozusagen der Qualitätswert. Unter die Hälfte des max. bpp Wertes wäre es schon fast ne Videokatastrophe 6,32 bpp sind für dieses Beispielvideo hier zu wenig. Der Wert müsste min. bei 8 oder 9 bpp liegen, damit noch was anständiges raus kommt.

Und wie gesagt die ABR Durchschittsberechnung hier ist nur ein ungefährer Wert. Wenn du mit VBR encodieren solltest, wird das wesentlich effektiver ausfallen.

Arten der VBR Encodierung sind z.B. die ABR mit 2pass, oder die konstante Qualität via CRF (x264) oder konstante Quantisierung (CQ).
Das letztere ist eine vereinfachte Form des konstanten Qualitäts Verfahrens.

Die letzten beiden genannten Verfahren brauchen keine Bitraten Angabe, sondern ermessen diese durch einen bestimmten Faktor. Quantisierungsfaktor bzw. Qualitätsfaktor.

Und bei der ABR Variante wird nach der Bitrate gegangen bzw. nach der Dateigröße. Je nach dem was man will.

Für Lossless Aufnahmen sind Bitraten also völlig uninteressant.

Zitat von Ancrion

Dann nehm ich RGB und Full und 709 falls kein Experte anderer Meinung ist

Bei RGB sind selbst bei OBS der Farbbereich als auch die Farbmatrix total irrelevant. Weil RGB besitzt weder ein Farbbereich außer den vollen von 0 - 255. Und die Farbmatrix ist nur für YUV Farbräume. Die hat mit dem RGB nix zu tun.

Als Hinweis:
Stellt man in OBS den Farbraum auf RGB und nimmt mit dem eingebauten x264 auf, so nimmt OBS das Video stets in YV12 (YUV 4:2:0) auf. Und dann sind lediglich der Farbbereich und die Farbmatrix relevant von den Einstellungen her. RGB jedoch wird dann als Einstellung verworfen.
Grund ist: x264 kann kein RGB an sich.

x264 könnte RGB identisch sein mit YV24 (YUV 4:4:4) + Vollbereich + BGR (RGB) Matrix

Könnte x264. Wird aber bei OBS nicht klappen, weil sich OBS mit der RGB Einstellung an den richtigen RGB Farbraum hält.

RGB ist mit OBS also nur mit den dafür vorgesehenden Codecs möglich. z.B. über FFmpeg mit UTVideo oder mit Lagarith oder oder oder....

Zitat von Ancrion

The difference between NV12 and YV12 is just how the bytes are arranged in memory, the image information is otherwise 100% the same.

NV12 ist gegenüber den normalen YV12 schneller, da bei NV12 besser mit dem Speicher umgegangen wird. Die Bildinformationen der beiden jedoch sind absolut identisch. Und fürs Streamen sollte man daher auch NV12 setzen.

Zitat von Ancrion

Kann jedoch bei Video-Encoder nichts auswählen.

Du musst vorher den Container Format bestimmen. Wenn du UTVideo nutzen willst, was RGB z.B. erlaubt, dann am besten als Container Format AVI nutzen.

Und dann solltest du auch den Encoder auswählen können.

Für Audio dann am besten pcm_s16le nutzen. Steht für Pulse-Code-Modulation (kurz PCM) - signed 16bit little endian.

Alle weiteren Angaben von wegen Bitrate für Video und Audio sind dann total irrelevant, weil du mit diesen Settings Verlustfrei aufnimmst. Das sind alles Lossless Codecs. Selbst Audio.

Zitat von Chron

Wenn bei größeren Treppeneffekten und Ringbildung mehr Bitrate von Youtube beim encodieren vergeben wird, was ja wünschenswert ist

Nein, ist es ja nicht Weil die Ringbildung oder auch die Treppenbildung als Detail erkannt werden und diese Muster sind unerwünscht. Sie benötigen mehr Bitrate, obwohl sie gar nicht im Bild sein sollten die Erscheinungen. Das heißt das Video bekommt mehr Bitrate und erreicht damit den Bitraten Cap womöglich den YT hat für diese Auflösungsstufe. Und dann passiert das was nicht erwünscht ist, nämlich das das Video zerlaufen tut oder anderswie Blöcke schmeißt.

Sowas sieht man z.B. bei Detailierten bewegenden feinen Gras, Bäumen oder anderen Vegetationen. Oder in Minecraft, wenn man wie ein Hase nur hopsen tut. Oder wenn es sehr sehr feine Texturen im Spiel sind wie z.B. sehr hochaufgelöste Texturen wie Sandkörnung etc. pp.

Für jeden verdammten Detail im Frame verbraucht der Frame mehr Speicher und somit über die Zeit hinweg mehr Bitrate.

Je unschärfer es wird, desto weniger wird benötigt. Je weniger Treppeneffekte drin sind und desto weniger Ringbildung vorhanden ist wird auch die Bitrate gesenkt.

Und bei YT bewegst du dich innerhalb einen Bitraten-Caps. Das heißt du bekommst max. so und soviel Bitrate zur Verfügung und es darf nicht darüber hinaus gehen. Geht es hinüber, wird dein Video halt schlechter, weil das Risiko somit größer ist das das Video Blöcke schmeißen tut bzw. zerfließen tut.

Je weniger Bitrate das Video benötigt, weil es halt keine Ringbildung oder Treppeneffekte hat und weil es vllt sogar noch Unscharf ist, kann es zu diesem Problem halt nicht kommen. Bzw. die Chance das das Video zu komplex wird ist damit gemildert und ergibt auf YT dann bessere Ergebnisse.

Zitat von Chron

Edit: Ahso, aber eine Frage zum Verständnis nur des Wissens halber - wieso wird auf Youtube die Qualität besser, wenn meine Videos unschärfer sind und Treppchenbildung haben? Hat YT dann nicht weniger klare Infos über die einzelnen Pixel und kann dadurch nur ungenauer arbeiten?

Spline16 hat kaum Treppeneffekte und Ringbildung. Spline36 schon mehr. Und Spline64 hat sehr viel.

Je schärfer ein Spline wird bei den Skalierern von 16 bis 64, desto Ringlastiger und Treppenstufiger wird er.

Das kannst du doch bei meinen Bildern doch ersehen die Ringbildungen. Die fallen da bei der 6x Skalierung regelrecht ins Auge.

Genau.

Wenn du noch höher skalieren tust deine 1080p Videos, dann ist der Skalierer auch sehr wichtig. Aber bei 72p halt voll banal schon. Spline36 ist neutral. Den kannste verwenden.

Zitat von Chron

Dann kann ich ja theoretisch gleich bei der Basisauflösung bleiben oder?

Die Bitrate deiner Videos wird bei Youtube anhand der Auflösungsgröße bestimmt die du hochlädst. Das heißt je höher die Auflösung ist die du auf YT hochladen tust, desto mehr Bitrate wirst du bekommen. Sprich die Encodierungen sind bei größeren Auflösungen auf YT besser.

Wenn man z.B. nur in 720p hochladen tut, kommt auf YT meist nur Matsch raus, weil YT einfach bei 720p kaum Bitrate zur Verfügung stellt.
Das sieht man auch noch bei 1080p Auflösungen.

Ab 1152p bekommst du den Encode der eigentlich für 1440p Videos gilt. Und die bekommen halt mehr Bitrate und sehen dann halt entsprechend besser aus.

Youtube arbeitet ein wenig anders für uns Verbraucher. Daher müssen wir uns da ein wenig nach YT richten.

Weil ein 720p Video kann zwars lokal sehr gut aussehen, wird aber aufgrund von YT Encode total matschig. Einfach weil die Bitrate nicht ausreichen tut. Und das sieht man dann halt auch. Das sieht man auch bei 1080p noch.

Zitat von Chron

Wieviel mehr gibt es denn wenn ich auf 2048x1152 bleibe? Sagaras meinte halt 72p wären gar nix, deshalb frag ich warum ich das dann machen soll

Damit meinte ich eigentlich das es Pumpe schon ist ob du nun Spline16 oder Spline64 oder was weiß ich nimmst. Weil 72p mehr kaum noch Sichtbar ist.

Das meinte ich ;D

Da du dich auf 1152p bewegst auf YT, ja. Das ist bei dir ein so geringer Skalierungswert das ist fällt dem Auge einfach nicht auf. Du hast doch selbst keinen Unterschied gemerkt bei deiner 1080 -> 1152 Skalierung mit den Spline Skalierern, oder?

Dann nimmst du halt Spline100 oder Spline16 und der Skalierer kann mehr auf YT erhalten, weil dir YT bei 1152p ohnehin nicht die Bitrate gibt die dein Video bräuchte. Also arbeitest du am besten so das sich der Encoder freuen tut über das Material.

Weiß ja nicht ob du schon bei anderen auf YT das gesehen hast, aber es gibt auch Games die benötigen bei bestimmten Frames soviel Bitrate, weil die Frames untereinander so komplex sind das YT diese Szenen total verwäscht und verschmiert. Regelrecht es in Blöcke darstellt. Und da wirkt man einfach entgegen, indem man das Video etwas unschärfer macht, bzw. im absoluten Notfall auch Motion Blur auf dem Video gibt.

Weil was nützt dir schon ein scharfes Bild was auf YT eventuell zerläuft, weil dein Video auf YT zu wenig Bitrate bekommt, als wenn du es etwas unschärfer machst und somit nicht noch zusätzlich vom Skalierer Ringing und Aliasing hinzufügst. Das spart Bitrate, die Encoder freuen sich und auf YT ist die Chance geringer das das Video zerfließen tut.

Optimal für einen Encoder sind auch Mod16 Auflösungen. Sprich Auflösungen wie 2048x1152, 2560x1440 oder 3840x2160

Das hat was mit den Macroblöcken zu tun mit den h264 als auch VP9 die Videos untergliedern. Um halt keine unnützen zusätzlichen Berechnungen zu machen, sind Mod16 Auflösungen eigentlich ideal.

Edit:
Bedenke bitte das du das für dich selbst entscheiden musst am Ende. Aber eine Skalierung von gerad mal 72p ist ein Pups im Wind Das ist gar nix.

Edit2:
Total Ideal wäre wenn du deine 1080p Videos mit Punktskalierern skalieren tust. Sowas wie xBRZ oder ganz simple mit Nearest Neightbour.
Das musst du allerdings in Faktoren dann tun. Sprich 2x bei dir.

1080p x 2 = 2160p (4k)

Zum einen wäre die Skalierung astrein und sauber und zum anderen würde dir YT womöglich bei einem so hochen Video kein Bitraten Cap aufdringen. Das kann dir aber gewiss @De-M-oN noch mal genauer erläutern.

Für Youtube würde ich jede Bitrate sparen die geht. Desto besser kann Youtube das Video selbst kodieren und die Chance das das Video auf Youtube in diverse Blöcke zerläuft wird damit minimiert.

Je mehr Ringbildungen und Treppeneffekte auf den Frames im Video, desto mehr Bitrate wird beim Encodieren vergeben. Daher am besten einen neutralen Skalierer verwenden wie Spline36 oder noch besser einen unschärferen wie Spline16.

Spline16 ist nämlich gegenüber Spline36 unschärfer. Und Spline64 ist gegenüber Spline36 schärfer.

Was ein wenig besser noch ist als Spline16 ist Spline100.

Du skalierst ja auch nur 72p nach oben. Was willst du da für einen Unterschied erkennen bei so einer lahmen Skalierung Klar das für das Auge alles identisch dann ist. Für den Encoder allerdings nicht. Der sieht da einen Unterschied.

Ich gib dir jetzt mal ein paar Beispiele zwischen den ein paar Skalierern, wo man den Unterschied auch mit dem Auge sieht.
Quelle ist ein RGB Video und skaliert wird um den Faktor 2:

http://killerinstinct.ath.cx:2…ptmaker/Vergleiche/a1.png
http://killerinstinct.ath.cx:2…ptmaker/Vergleiche/a2.png
http://killerinstinct.ath.cx:2…ptmaker/Vergleiche/a3.png
http://killerinstinct.ath.cx:2…ptmaker/Vergleiche/a4.png

Da es nur eine sehr kleine Skalierung ist nimmt das Auge relativ wenig war. Die Unterschiede sind aber bei Spline16 und 64 schon vorhanden. Man kann es an den Schriften schon erkennen das Spline64 schon Ringbildung aufweist. Selbst Spline36.

Und nun noch mal ganz Verschärft mit einem Faktor von 6x skaliert (Bitte Geduld haben bis das Bild geladen ist.):
http://killerinstinct.ath.cx:2…tmaker/Vergleiche/a5h.png
http://killerinstinct.ath.cx:2…tmaker/Vergleiche/a6h.png

Hier sieht man die Unterschiede nun sogar mit bloßen Auge schon. Und das kann aber der Encoder schon mit kleinen Auflösungen ersehen.

Zitat von TbMzockt

Wenn man das "so" macht, dann HÖRT man den Unterschied, die "neuen" Abtastwerte passen Zeitlich NICHT in die bisherigen und das äußert sich indem der Ton "Digital-Knistert", er klingt schlichtweg nicht gut.

Also ich habe genau wie du es gerade beschrieben heute ausprobiert gehabt. Ein 44100Hz Audio genommen und knallhart auf 192000Hz hochgedreht, dann auf 48000Hz runter und auf 96000Hz und dann wieder auf 44100Hz (Original) runter. Dabei habe ich immer wieder die Frequenz geändert.

Ergebnis: Kein Knistern. Perfekte Qualität wie vorher auch.

Dann habe ich die geänderte WAV gespeichert die ich permanent jedesmal die Rate geändert habe, als auch das Original. Und zwars beide jeweils auf 44100Hz 16Bit PCM signed little Endian.

Dann sogar mit dem HxD Editor geöffnet und einen Datenvergleich vorgenommen. Was meiste was daraus gekommen ist? Ich finde es dann schon komisch das die Datei exakt die gleichen Werte aufwies. Obwohl die eine eine permanente Abtastratenänderung hatte.

Zitat von TbMzockt

Also nimmt man ALLE Samples, errechnet sie neu und "verlängert" sie.

Du meinst mit dieser Aussage aber diesen Werdegang: 44100 Hz auf 32000 Hz. Dann würden die Samples länger werden, sprich die Periodendauer. Und dann entfallen ja Samples bei der Neuinterpolierung. Ergo Informationsverlust. Und dann wird das Ganze dumpfer, da die Wellen immer länger werden.

Andersrum aber kann ich dir garantieren das da nix passiert mit der Audiospur. Das habe ich mir sogar von einem Tontechniker erklären lassen

Du kannst mit 44100 Hz aufzeichnen, es mit einer Trägerfrequenz von 192kHz übertragen lassen oder speichern. Und hast im Endeffekt wenn du es wieder upsamplen tust auf 44100 Hz exakt das gleiche Muster das du aufgenommen hast.

Das kannst du gerne ausprobieren oder auch im Netz nachlesen.

Weil es entfallen doch nur wieder die dazuinterpolierten Sachen.

Ich glaube fast das du nicht so richtig verstehst was da genau passiert

Die Samples die schon existieren bleiben erhalten, werden aber nur kürzer. Für den Zeitlichen ausgleich kommen dazu interpolierte Zwischen Samples die sich vom Kurvenverlauf vom vor- und nachgehenden Samples ergeben.

Da kommt kein Rauschen, kein Knacksen, gar nix. Da passiert einfach nix. Ein Knacksen würde dann entstehen, wenn ein Sample zwischendurch einen Abrupten Unterschied aufweist. z.B. wenn man am Klinkenstecker die Spannung abreißen tut.

Ein Knacksen und hat man auch wenn bei einem Emulator Audio Video Synchronisation an ist und Audio auf Video abgestimmt wird. Weil wenn Audio den passenden Bild überholt, wird neu synchronisiert und dann entsteht ein knacksen, weil das Bild nicht hinterher kommt.

Aber so... wie gesagt... ich kann das mit AVISynth machen, ich kann das mit Audacity machen... und da passiert einfach nix an der Qualität wenn ich die Samplerate da ändere. Solange die Samplerate >= original Samplerate ist. Ist die Samplerate < als original Samplerate werden Samples gelöscht die nicht wiederhergestellt werden können. Das wäre ein Qualitätsverlust.

Ist doch das gleiche Prinzip bei den FPS.

Du kannst in 60 FPS aufnehmen, kannst es in 61, 70, 80 hoch ändern und dann wieder auf 60 und hast wieder die exakten Frames des Originals. Andersrum 60 auf 30 und dann auf 25 und wieder auf 60 bringt einen 0. Weil einfach wichtige Frames schon weg sind und das Video eigentlich nur noch ein 25 FPS Video ist.

Zitat von TbMzockt

Du erzeugst nur ohne ALLE Samples neu zu berechnen (interpolieren) etwas das mit einem VFR-Video vergleichbar ist, darum gehts mir hier nur, du MUSST es KOMPLETT neu berechnen und kannst nicht einfach Samples "Kopieren" wie oben geschrieben wurde.

Audio kennt keine variablen Samples Und die neuen Samples die hinzukommen bei einer Audiosampleänderung sind immer Zwischenwerte. Klar werden diese Interpoliert. Aber dadurch geht doch nix verloren wenn du 44100 auf 48000 Hz anhebst und dann wieder auf 44100Hz senken tust. Die Samples die vorher bei 44100Hz da waren, sind es noch immer. Da tut sich doch nix. Das kannst du auch auf 99999999999 Hz anheben und wieder auf 44100 Hz absenken. Audio bleibt immernoch identisch, sofern du keine Filter darauf hauen tust. Da geht nix verloren.

Anders herum schon.

Zitat von TbMzockt

Doch klar... durchs Upsampling erzeugst du neue Zwischenwerte und die alten werden durch Interpolation verändert, als würdest du ein Video hochskalieren und danach wieder runter und behaupten es kommt dann trotzdem 1:1 das selbe raus wie vorher.

Kann ich leider nicht reproduzieren. Daher wäre es interessant wie du verfährst.

Und was hat das jetzt mit Hochskalieren zu tun? Absolut NULL.
Vergleiche es lieber mit FPS Änderung. Das trifft es sehr genau.

Audio ist am PC leider digital und nicht analog. Daher ist dieses Linienmuster was man so oft sieht wie in Audacity meist falsch. Im Grunde sind es Rechtecke bzw. Linien. Jeder Sample stellt eine waagerechte Linie dar. Der Sample ist die Periodendauer, denn ein Sample hat eine bestimmte Zeit. Die hab ich dir im letzten Beitrag sogar ausgerechnet für 44100Hz. Und solange geht ein Sample. Und die Samplefrequenz sagt nun wie schnell nun das alles passiert. Denn nach jeder ca. 0,0227 ms fängt ein neuer Sample an.

Der Sample ist ein Klangmuster (daher Sample (Probe)) von einer Tonhöhe im Bereich der 16Bit, sofern man in 16Bit aufgenommen hat.

Und nun haste das Bild eigentlich schon.

Bei einer Frequenzänderung werden neue Samples in das Muster einberechnet (interpoliert) und ergeben das exakt gleiche Muster des Audiotracks.

Wenn man es auf den gleichen Wert den der Track vorher hatte wieder eine Frequenzänderung vornimmt, passiert der Audiospur gar nix. Einfach weil die Ursprünglichen Samples immer noch enthalten sind.

Das ist ne ganz einfache Sache eigentlich. Ich weiß gar nicht warum du dich da so schwer hast mit grad?

Es gibt noch das andere Upsampling wo die Samples erhalten bleiben, sich aber ihre Periodendauer ändert. Sprich da kommen bzw. entfallen keine Samples. Dadurch das bei diesem Verfahren dann die Frequenz geändert wird, kann man Audio dehnen und zerren. Was dann halt das eigentliche Audiosignal verfälscht. Wenn man es dehnt (Downsampling), dann wird das Audiosignal halt langsamer, da längere Periodendauer und quetschen tut (Upsampling), dann wird das Audiosignal schneller, da kürzere Periodendauer.

Zitat von TbMzockt

In der Elektrotechnik schon und eine Soundkarte arbeitet (im Gegensatz zum Ohr) nun mal so...

Die Elektrotechnik verfährt genauso wie ich den Merksatz aus der Physik geschildert habe.

Die Frequenz ist nicht die Änderung einer Spannung über die Zeit so wie du gesagt hast.

Die Frequenz ist eine Geschwindigkeitseinheit mit der man in der Elektrotechnik angibt wie schnell Spannung in einer Sekunde fließt. Oder Leienhaft ausgedrückt wieviel Schwingungen pro Sekunde anfallen.

Und der Kehrwert bildet die Periodendauer einer Spannung. Sie gibt die Dauer des Schwingungsverlaufs an.

Von mir aus können wir uns über Elektrotechnik streiten was die Grundsätze von Spannungsfrequenzen angeht, aber ich denke das meine Professoren an der Hochschule mir nix blödes beigebracht haben

Zitat von TbMzockt

Wir wissen das du Wikipedia zitieren kannst, das brauchst nicht in jedem 2. Beitrag machen um dich über andere zu stellen und dich besser zu fühlen... (ich habe den Beitrag aus dem Kopf geschrieben und erst beim editieren was dazu rausgesucht)

Ich brauch mich nicht besser fühlen dabei, bei etwas was ohnehin klar definiert ist. Das sind Merksätze aus der Physik. Die solltest sogar du schon mal irgendwo gehört haben. Und ab und an mal was auf Wikipedia oder anderen Quellen was zu nutzen um Sachen halt klar zu stellen, sofern man sie dann auch verstanden hat, ist kein Delikt. Ich muss schließlich die Sätze nicht neu erfinden, sie stehen ja im Netz und in jedem Physikbuch.

Wenn du möchtest, kann ich dir auch aus mein Elektrotechnik Buch das gerne noch mal den Merksatz formulieren. Wird das gleiche bei raus kommen.

Zitat von TbMzockt

War ein sehr simples BEISPIEL... darauf einzugehen war nicht nötig.

Moment... du sprichst ein Beispiel an, weil du glaubst das es ungefähr so arbeitet. Ich gehe darauf ein, weil mir das unbekannt war und frage noch wie du dazu kommst bzw. wie ich sowas selbst reproduzieren kann. Und dann sagst du das es unnötig war auf dieses Beispiel einzugehen?

Wenn du mir erklären kannst wie du zu solch ein Beispielmuster kommst, wäre ich auch vllt. auch ein Tick klüger. Aber anscheinend darf man das nicht hinterfragen. Weiß ich nicht.

Zitat von TbMzockt

Der AD-Wandler benötigt eben mindestens die Doppelte Frequenz die er erfassen soll, ist normal und habe ich bisher auch nicht wirklich hinterfragt wieso...

Einmal wegen den oberen und einmal wegen dem unteren Frequenzbereich. Daher macht man das so.
Und dann kommt man halt von einem 22,05 kHz Mikrofon auf eine 44,1 kHz Aufnahme.

Zitat von TbMzockt

Eine Frequenz ist die Änderung einer Spannung über die Zeit, steht die Zeit still hast du eine Spannung aber keine Frequenz mehr.

Frequenz ist nicht die Änderung einer Spannung über die Zeit.

Eine Frequenz ist ein Kehrwert einer Periodendauer (Schwingungsdauer). Und die Periodendauer ist der kleinste örtliche oder zeitliche Intervall nachdem sich der Vorgang wiederholt. Im Falle von normalen Audio ist damit der Abstand zwischen zwei naheliegenden Samplepunkten gemeint.

Bei 44100Hz hat man somit eine Periodendauer von ~0.022675737 ms.

1 / 44100 Hz = 1 / 44100 * 1/s =
  1    *   1
44100  *   s
T = 1 * 1 / 44100
T = 1 / 44100 / 1000  | s in ms
T = 1 / 44,1 ms
T = 0,02267573696145124716553287981859..... ms

Und wenn man Audacity mal öffnet und ganz nah an eine 44100Hz Tonspur ranzoomt, dann müsste man auf diese Zeitlänge kommen für ein Sample.

Die Frequenz hat in der Elektrotechnik Anwendung, ja. Aber hier geht es um den Physikalischen Hintergrund allgemein. (Das Zeug was man eigentlich in der Schule hatte ^^)

Denn du selbst hörst auch mit einer bestimmten Frequenz und die besteht gewiss nicht aus Spannung, sondern hat einen physiologischen Hintergrund.

Zitat von TbMzockt

Ein Kompressor reduziert nur die Lautstärke, sprich die maximale Spannung die ein Sample wiedergibt und ändert NICHTS an der Frequenz

Ein Kompressor komprimiert erst einmal wie der Name schon deuten lässt. Das ist Fakt Nummer eins.

Eigentlich heißt das Ding ganz genau Dynamikkompressor, denn es wird der Dynamikumfang eines Signals eingeschränkt.

Je besser der Frequenzbereich nun ist, desto Zielgenauer kann er arbeiten. Oder besser gesagt: Desto feiner kann er arbeiten. Und das macht man in der Regel auch das man mit der Frequenz höher geht bevor man unangenehme Kompressor Geräusche bekommt. Weil ein Kompressor sollte man wenn es geht vermeiden.

Zitat von TbMzockt

Nachher (48khz) bei schlechter Wandlung:
- 2-4-4-8-2

So eine Audiofrequenz würde ich gern mal sehen.

Das wäre ja sehr eckig Mit was arbeitest du um sowas zu bekommen? Weil VirtualDub kann das nicht und AVISynth auch nicht. Daher frage ich mal so

Das Grundprinzip ist immer das ein kleinerer Frequenzbereich immer in einen höheren geht. Es werden lediglich an den Stellen Samples hinzugefügt wo schon was da ist.

Sprich: Zwischen zwei Samples liegt eine Gerade und auch nur da kann wird ein neuer Samplepunkt angelegt. Das ist für gewöhnlich der rudimentärste Weg.

Daher passiert einem 44100Hz Audio auch rein gar nix, wenn du es in 128000Hz und dann in 50000Hz und dann wieder auf 44100Hz zurück samplen tust. Einfach weil das was schon da ist mit 44100Hz nicht mehr weg genommen werden kann. Du vergrößerst doch nur die Box. xD

Das ist wie mit den FPS bei nem Video. Du nimmst in 30 FPS auf und blähst es auf in 41, 50 oder höher. Und was hast du dann? Richtig, nicht mehr als die 30 FPS die Sichtbar ist. Wenn du das wieder auf 30 runter machst, bekommst du exakt die Frames wieder die du vorher auch hast.
Ergo kein Verlust.

Anders sieht es aus wenn du in die andere Richtung wanderst. 44100 Hz in 22050 Hz oder solche Scherze. Dann wird Audio immer Dumpfer. Hier löschst du dann einfach Informationen.

Das ist wie bei der FPS auch. 60 FPS auf 41 FPS und wieder auf 60 und man hat eigentlich nur 41 FPS optimal. Anders verhält sich das bei Audio auch nicht.

Damit Audio metallisch klingt ist dafür die Audiotiefe da. 16Bit auf 8Bit und man hört es langsam aber sicher Metallischer, einfach weil die Tonhöhen gar nicht mehr existieren die bei 16Bit noch vorhanden waren.

Daher ist die Audiotiefe genau das gleiche Prinzip wie mit dem Farbraum bei einem Video. YV12 gegenüber YV24 oder gar RGB sieht mistig aus. Und genau das gleiche ist es wenn du 8Bit Audio vs 16 Bit Audio antreten lässt.

Und wie gesagt... so ein komisches eckiges Verhältnis wie du es da aufgeschrieben hast, habe ich noch nie gesehen

Zitat von GelberDrache92

Sollte man jetzt mit 30 Fps aufnehmen, sind 5 Fps einfach nur Dummy Frames, die die auf den weg zu 25 Fps einfach entfernt werden.

Das ist ein Punkt, den kannst du einfach nicht mehr vergleichen so. Da macht es sich nun Bemerkbar was FPS ist und was Sampleraten sind.

Bei einem Video mit einer so niedrigen FPS wie 60 und auch dessen das Aufnahmeprogramme durch Hooking bzw. auslesen des Bildspeichers und dessen Speicherung auf der Festplatte enorm viel Zeit zwischen liegt.

Theorie:
Würde man bei einem exakten 60 FPS Spiel mit 60 FPS aufnehmen, würde es im Idealfall zu keine Dummy Frames kommen. Einfach weil jeder Frame nun anders wäre.

Praxis:
Da wie angesprochen durch Hooking und sonstige Hindergrundprozesse das etwas ausgebremmst wird läuft ein 60 FPS Spiel ja nicht mit 60 FPS, sondern variiert. Weil ein Spiel und ohnehin alles was ein PC oder eine Konsole wiedergeben eine VFR ist. Und die wird in den meisten Fällen konstant aufgenommen. Und daraus resultieren dann die Dummy Frames. Das sind dann halt Kopien die an irgendeiner Position x liegen.
Und die kann man nicht einfach so entfernen, da es ein unregelmäßiges Aufteilungsverhältnis ist.

Das hat man aber bei Audio in der Regel gar nicht. Daher kommen Mikro Ruckler wie @TbMzockt das angesprochen hat halt nur bei Computeranwendungen vor. Meist hervorgerufen durch Grafikkartenprobleme.

Erst einmal sag ich dir das ich dir keinen Speziellen empfehlen kann, weil diese Signalverstärkung bei jedem HDMI Splitter auftaucht und somit eigentlich jeder HDMI Splitter somit in der Lage wäre HDCP zu umgehen.

Die Frage wie hoch die Signalverstärkung ist, ist daher Hardwarebedingt vom HDMI Splitter selbst. Das hängt von der Verbauung ab im HDMI Splitter.

Da hilft ausprobieren.

Ist leider wirklich so.

Du kannst mit ein HDMI Splitter auch pech haben und bekommst permanent ein schwarzes Bild (HDCP Verschlüsslung) oder das Signal wird so dermaßen damit verstärkt das es ausreicht um HDCP zu umgehen. In diesem Fall bekommst du ein Bild.

Ich hab z.B. ein Ligawo HDMI Splitter 1 zu 2. Und der funktioniert bei mir.
Andere Leute haben aber auch andere Marken und funktioniert ebenfalls. Daher ausprobieren.

Nein. Bei der PS3 war und ist es bis heute nicht möglich HDCP zu deaktivieren. Bei der PS4 geht das aber Wunderbar War auch eines der Features die Gewünscht waren bevor die PS4 raus gekommen war.

Bei der PS4 sieht man das an schwarzen Szenen im Bild, wenn man die PS4 im PC Range nutzt. Wenn "HDCP deaktivieren" aktiv ist, sieht man, wenn man genauer hinschaut, kleine weiße Punkte ab und an irgendwo aufflackern. Das ist eine Folge der Signalverstärkung um HDCP zu umgehen.

Schaltet man bei der PS4 "HDCP deaktivieren" wieder aus, so entfällt dieses Rauschen/Signalverstärkung.

Für Gewöhnlich fällt das einen nicht sonderlich auf und gerade am Fernseher nicht. Aber die PS4 nutzt genau das gleiche Verfahren HDCP zu umgehen indem das Signal einfach verstärkt wird.

Ist zwars sehr Bescheidend von Sony gelöst, aber der Effekt sollte klar sein.

Zum einen sichert sich Sony sich teilweise damit ab und zum anderen würde ohne HDCP die Share Taste auf der PS4 recht Sinnbefreit werden für bestimmte Dinge.

PS3 HDMI Übertragung jedoch ist bis heute HDCP Verschlüsselt und kann nicht deaktiviert werden.

@RealLiVe

Etwas Fail ist es ja schon, wenn selbst FFmpeg es als Video mit x FPS anzeigt die sich halt bei jeder Shadowplay Aufnahme auch variiert. Heißt im Endeffekt, dadurch das jedesmal andere FPS Werte erscheinen bei einer Shadowplay Aufnahme, das es keine Konstante FPS sein kann.
Und das Belegen sehr viele User im Netz.

Zumal kennt @LeNerd ja nicht mal den genauen Wert von Double NTSC (60 / 1,001), geschweige den gerundeten Wert von 59,940

Weil 59,5.... wäre ja eine so dermaßen bescheuerte FPS Angabe... das wäre ja mal total Fail.

Zumal die Mediainfo noch sagt das es sich um VFR handelt und es 60 FPS sind.

Und das deckt sich auch mit den Problemen bei den Programmen und der dadurch entstehenden Asynchronität.

Einzig und allein wenn die VFR Aufnahme annähernd so aufnimmt wie CFR, dann können auch Programme die ohnehin Videos in CFR laden auch diese VFR Aufnahmen laden. Und genau darin besteht das Risiko. Wer gibt einen die Sicherheit das es so läuft? Bei CFR ist man da sicher.

Naja, VFR hat ja an und für sich auch Vorteile. Jedoch können bestimmte Softwares VFR einfach nicht einlesen, weil sie das in CFR laden und CFR ist falsch.

Problem ist auch, man kann diesen Zeitunterschied nicht einfach durch zerren oder drücken der Spur korrigieren. Das geht einfach nicht. Einfach weil Frames fehlen oder auch zuviel sind. Die werden als CFR geladen, obwohl sie unterschiedliche Abstände zueinander haben.

Daher braucht es einen VFR -> CFR Wandler. Und das bieten nicht alle Programme an.

Der VFR -> CFR Wandler sorgt dafür das bestimmte Frames entfallen bzw. fehlende ergänzt werden. Einfach weil ein Schnittprogramm gar nicht in der Lage wäre VFR darzustellen

Sieht nämlich etwas doof aus wenn man eine Timeline vor sich hat die sich in Zufälligen Zeitphasen darstellt.

Daher wird das Schnittprogramm welchen VFR einlesen kann einen VFR -> CFR Wandler anwenden.

Dabei wird der Index analysiert (max. Framesanzahl) und die Aufnahme FPS die zur Verfügung steht im Header oder auch manuell irgendwo angegeben wird. Intelligente Software nutzt dabei meist den Header. ODER es wird sich nach der Zeit orientiert. Meist aber die original FPS

Und dann wird nicht nur entschlüsselt, sondern auch neu berechnet.

Beispiel:
1953 Frames bei 1min mit einer VFR von 30 FPS

30 FPS * 60sek = 1800 Frames (CFR)

Heißt das genau 153 Frames zuviel sind an irgendwelchen unbekannten Positionen.

Jetzt kommt der Index ins Spiel der sagt wo sich diese Frames Zeitlich befinden. Und dann wird gerundet, bzw. es wird sich angenähert. Immer an den nächst gelegenen Frame der dem CFR Wert am nächsten ist.

So macht es z.B. FFMS2 und L-Smash die das halt über AVISynth kostenlos machen.

Eigentlich ist das der Gewöhnliche Werdegang um VFR in CFR zu wandeln. Die Werte die dem CFR Wert am nächsten liegen werden aus dem VFR Index genommen und der Rest verfliegt. Bzw. wenn im VFR Index kein Bild zu der CFR Zeit anliegt, wird der davor liegende Frame einfach dupliziert.

Um am Ende stimmen Zeitangaben, FPS und auch Bild zu Ton ist dann in der Regel Synchron.

Erst einmal:
Ein Komponenten Kabel liefert nur ein YUV 4:2:0 Signal ala YV12.

Dabei steht
Y (Grün) = Luminanz (Helligkeitsanteil)
U [Pb/Cb] (Blau) = Chrominanz (Farbanteil) für Blau
V [Pr/Cr] (Rot] = Chrominanz (Farbanteil) für Rot

Dadurch das ein Signal auf 3 Chinch verteilt wird, kann man somit eine Chinch Übertragung optimal ausnutzen indem jede der 3 Analog Übertragung (was Chinch ja ohnehin ist) ihren eigenen Anteil überträgt.
Was bei FBAS (Gelber Chinch für Video) nicht gehen würde, da hier alle Signale über ein Chinch laufen und somit nicht optimal übertragen kann.

Daher ist ein Komponenten Kabel der FBAS Übertragung immer besser.

S-Video wäre ein Zwischending aus FBAS und Komponenten Kabel. FBAS und S-Video können auch auf SCART laufen, sofern der SCART-Kopf die nötige PIN-Belegung hat.
Was bei PS3 recht milde belegt sein sollte und somit nur FBAS möglich macht.

Das sind aber alles sogenannte Analog Übertragungen und daher können sie Rauschmuster oder sonstige Kleinigkeiten an Bildstörungen haben.

Daher ist das bei einer PS3 und höher nicht grad toll. Bei einer PS2 hätte ich sogar noch auf Komponenten Kabel viel Wert gelegt, da hier kein HDMI möglich ist im Normalfall.

Zum anderen:
HDMI bietet eine digitale und native Übertragung des Bildes. Das heißt das Signal kann nativ mit einem RGB Signal übertragen werden, was für optimale Bildqualität sorgt.

Einziges Problem bei der PS3 wird der HDCP sein. HDCP kann man bei der PS3 nicht deaktivieren und sorgt dafür das das Signal am HDMI Ausgang Verschlüsselt wird. Die normalen einzigen Entschlüssler die man Zuhause hat sind meist der Fernseher oder auch irgendein Receiver die mit HDCP zertifiziert wurden.

Man kann seit 2010 das HDCP Signal mit einen Master Key bereits entschlüsseln (Master Key)
Da es aber gewiss nicht so einfach bei der PS3 wird, nützt einen der Master Key hier auch nicht viel, sondern eher was für BluRay Ripper ;D

Das HDCP lässt sich aber auch anders enthebeln indem einfach das Signal was von HDMI kommt geändert wird. Entweder durch massive Frequenzänderungen (Rauschmuster) oder was natürlich noch viel besser und einfacher ist: Das Signal aufteilen (splitten)

Und das macht man mit einem HDMI Splitter.

Grund dahinter: Ein HDMI Splitter arbeitet bei der Aufspaltung das Signal auf 2 oder mehr HDMI Ausgänge zu "duplizieren" mit einer kleinen Abschwächung des eigentlichen Signals. Das heißt das diese Abschwächung dafür sorgt das die Frequenzleistung nicht mehr ausreicht um das HDCP aufrecht zu erhalten und das HDCP somit umgangen werden kann.

Hinweis: Dies geht lediglich wenn es sich um eine Live HDCP Übertragung handelt. Was ja bei einer Konsole der Fall ist
Für BluRays die mit HDCP verschlüsselt sind gibt es entsprechend Software die den Master Key nutzen und somit das Signal in einem 1a Zustand entschlüsseln und somit auch kopierbar machen. Das ist aber eine andere Geschichte.

Also, das Signal wird aufgespaltet mit so einem HDMI Splitter und gleichzeitig wird auch die Frequenz etwas geändert was den HDCP entschlüsselt. Wichtig ist hier das dies nicht jeder HDMI Splitter kann. Es muss ein bestimmtes Rauschmuster erreicht werden, bevor das Signal entschlüsselt werden kann. Daher vorher schauen welchen HDMI Splitter man nimmt. Am besten solche nehmen mit denen mehrere Leute schon erfolg mit hatten.

Ein weiterer Vorteil eines HDMI Splitters ist auch der das man das Signal somit an den PC schicken kann und gleichzeitig auch noch an den Fernseher, wodurch es keine Verzögerungen der Aufnahmesoftware bzw. halt der Aufnahmehardware gibt.

Zitat von De-M-oN

Und der samplerate konverter von audacity ist zudem wahrlich für die tonne

Sollst ja auch nicht konvertieren, sondern ändern. Da passiert doch rein gar nix mit den Audiodaten.
Tonspur auswählen -> Spuren -> Samplefrequenz der Spur ändern
Und dann neue Samplefrequenz angeben.

Sofern niedrige in höhere umgewandelt werden, passiert mit der Samplefrequenz rein gar nix. Da kommen höstens neue Frequenzpunkte zu.

Das ist das gleiche als wenn du die FPS ändern tust bei Video mit ChangeFPS.

Und wenn es von 44100 Hz auf 48000 Hz geändert wurde, dann muss die Projektfrequenz ebenfalls auf 48000 Hz umgestellt werden.

Warum nix passiert: ist weil einige Samples kopiert werden nur bei dieser Art von Änderung.

Höhere in niedrige Frequenzen zu samplen ist bei dieser Methode auch recht ok noch. Jedoch werden dann Samples entfernt und und wie bei niedrigen FPS man die Bilder dann sieht, hört man bei Audio dann halt entsprechend einen dumpfen Klang. Einfach weil die Samples weiter auseinander liegen dann. Bei höheren liegen sie näher zusammen und sind daher klarer im Klang.

Diese Methode ist im Aspekt der Samples und Sampletiefe und auch von der Zeitlänge absolut Lossless. Es werden halt nur Samples hinzugefügt (kopiert) oder entfernt. Mehr ist das nicht. Würde AVISynth genauso machen.

Ab 30000 Hz bis 300000 Hz bewegt man sich dann im LW Bereich. Langwellen Bereich halt.

Das sind Signale die für Radios genutzt werden. Diese Signale können sich nicht beugen und würden daher wenn ein Empfänger hinter einem Berg liegen würde den Empfänger nicht erreichen. Einfach weil Langwellen sich nicht beugen können.

Bei UKW sieht das dann anders aus. Das geht dann aber erst ab 30.000.000 Hz (30 MHz) los.

Bei 192 Hz also ist man im LW Bereich, hat aber Studioqualität, weil einfach mehr Samples pro Sekunde zur Verfügung stehen und somit das Klangergebnis pro Sekunde auch deutlich verbessern damit.

Das ist wie gesagt wenn man jetzt ein 25 FPS Video (22050 Hz) mit einem 60 FPS Video (44100 Hz) vergleichen tut. (Ist jetzt nur mal eine Gegenüberstellung wie man das sehen sollte. ^^)

Zitat von GelberDrache92

Wenn man in mehr Bit aufnimmt, können Filter im nachhinein besser arbeiten, zudem wird dann auch das Risiko reduziert das man übersteuert.
Nur muss man dann in nachhinein diese Werte auch ordentlich Downsampeln und dafür ist Audacity nicht geeignet, da selbst Avisynth hier schon bessere Ergebnisse erzeugt.

Die Sampletiefe (Bit) gibt an wie welche Klang/Ton Höhe erreicht werden kann.

Bei 8 Bit können 256 Tonhöhen erzeugt werden.
Bei 16 Bit schon 65536
Bei 24 Bit 16777216
Und bei 32 Bit 4294967296

Ist es 32 Bit Float können sogar Gleitkommazahlen als Tonhöhe erzeugt werden.

Das ist dann die Qualität einer Audiospur und ist ähnlich gleichzusetzen mit der Video Farbtiefe.

Hier macht Audacity eigentlich auch nix falsch. 16 Bit Audio in 32 Bit und dann wieder in 16 Bit zu konvertieren erzeugt 0 Verlust, da die Samplehöhen sich ja nicht geändert haben.
Übrigens macht das AVISynth genauso wie Audacity.

Daher ist es Schwachsennig in höheren Sampletiefen wie 24Bit oder 32Bit aufzunehmen, bzw dort Audio zu bearbeiten. A) YT. macht eh nicht mehr als 16 Bit, B) Qualitativ bringt das einen eh nix, da höhere Tonhöhen bei einer Sampletiefenänderung in eine niedrige auf ein kleineres Spektrum gequetscht werden.

Klar ist aber: Je niedriger die Bitzahl, desto weniger Tonmuster hat man zur Verfügung und desto radiomäßiger wird der Ton. Je höher, desto klarer wird ein Sample, da mehr Tonmuster zur Verfügung stehen.

16 Bit mit 65536 Tonmuster von Stumm (0) nach Laut (65536) reicht im Normalfall.

Das ist meist auch ein Punkt weshalb Audio manchmal auch Übersteuern kann, indem sich nicht mehr innerhalb dieser Grenzen bewegt wird, sondern darüber hinaus.

Beide Sachen macht Audacity eigentlich ganz gewissenhaft. Kann mich nicht entsinnen das AVISynth anders verfährt.

Das Speichern unter Audacity richtet sich nach der Projektfrequenz.

Die Bittiefe richtet sich nach dem verwendeten Codec.

z.B. wenn ich ein 48000 Hz 24Bit Audio Track habe, dann stelle ich die Projektfrequenz auf 48000 Hz und exportiere den Ton mit:
Andere unkomprimierte Dateien -> Optionen... -> Header (WAVEX (Microsoft)) ; Codec Signed 24 Bit PCM -> OK -> Speichern

Und schon hat man an der Audiospur nix geändert, da alle Parameter nun passen.