Diskussion:Bitrate

LA

Die Löschung der Seite „Bitrate“ wurde ab dem 1. April 2007 diskutiert und abgelehnt. Für einen erneuten Löschantrag müssen gemäVorlage:SS den Löschregeln neue Argumente vorgebracht werden.

eingefügt von mir - --Ricky59 15:24, 2. Mai 2007 (CEST)

FLOPS?

• Die Datenrate bezeichnet das Verhältnis einer Datenmenge zu einer Zeit.
• Als Floating Point Operations Per Second (Flop/s) für die Datenverarbeitungsgeschwindigkeit von Mikroprozessoren

da passt aber was nicht:

• Flops messen die Rechengeschwindigkeit, also Operationen pro zeit. eine Operation ist aber keine „Datenmenge“, die sich in bit messen lässt..
• oder ist die datenrate vielmehr Information je Zeit, weil ja die Datenmenge die Anzahl der Informationseinheiten ist, also von derselben physikalischen Dimension - so wie Strecke die Anzahl der Längeneinheiten ist: Länge entspricht Strecke, Datenmenge entspricht Information - wieso heisst sie dann aber „Datenrate“ und nicht „Informationsrate“? -- W!B: 02:45, 17. Aug. 2007 (CEST)
• zu Datenrate: diese wird nicht in bit/s sondern in Bit/s angegeben. Das ist ein wichtiger Unterschied. Siehe dazu Artikel: Shannon(Einheit)

Überarbeiten: Indexposition

Unter Bitrate#Technischer Hintergrund steht:

Die Abspieldauer von VBR-kodierten Dateien kann im Vorfeld häufig nicht exakt bestimmt werden, da sich aus der Dateigröße aufgrund der schwankenden Datenrate vor Kenntnis der konkreten Daten keine Zeit errechnen lässt. Das Vorhalten der benötigten Metainformation ist bei Streaming-Anwendungen nicht möglich, wird jedoch beispielsweise bei statischen Videodateien realisiert: am Ende der Datei werden Indizierungspositionen gespeichert, so dass erst mit der vollständigen Datei ein Spulen im Film möglich ist. Anderenfalls würde die Videosoftware blind in einem langem Datenstrom umhertappen, was zu den bekannten Artefakten wie fitscheln oder schlieren führt.

Das scheint mir zu sehr auf ein konkretes Format bezogen zu sein (klingt nach AVI). Denkbar wäre auch, den Index an den Anfang der Datei zu setzen. Anders macht es soweit ich weiß Ogg, dort werden glaub ich in den Datenstrom Informationen eingefügt, an welcher Position man sich gerade befindet. Aus en:Ogg page:

Each Ogg page also provides the time offset of the contained data which allows efficient seeking which works with streaming and time accurate. In contrast, many other formats seek to byte positions in the stream or rely on a table of contents for seeking information.

– 91.4.55.39 03:13, 3. Sep. 2007 (CEST)

Zielgruppe?

Liebe Leute, selbst wer sich Jahre lang, wenn auch nicht beruflich, mit Computern befasst, hat nach diesem Artikel immer noch keine rechte Vorstellung davon, wie sich nun die Megabits, in denen Daten aus dem Net gesogen oder auf externe Festplatten geparkt werden, zu den intuitiv dem Laien viel leichter eingängigen Megebytes verhält. Die Zielgruppe kann ja hier wohl nicht nur die Informatiker-In-Group sein!--Ulizinho 13:58, 20. Dez. 2009 (CET)

Die Anzahl der Megabits verhält sich zur Anzahl der Megabytes (in etwa) wie acht zu eins.-- 89.204.153.132 03:54, 11. Aug. 2010 (CEST)

Verlustfreie Kompression obligatorisch VBR

Zu dieser Änderung:

• Da es nur um die Kompression geht, hängt es nicht vom zu digitalisierenden Signal ab; das Digitalisieren ist zum Zeitpunkt der Kompression abgeschlossen.
• Kommen bestimmte Werte ganz sicher niemals vor, braucht man auch keine Codewörter dafür reservieren. Kodiert man z. B. nur die Werte −1, 0, 1, nicht aber -2, so kommt man im Schnitt (bei zufälligem Signal) mit $log_{2}(3)$ Bit aus. Siehe auch Shannon-Fano-Kodierung. Das wäre dann aber auch schon VBR. Anderes (durchaus mal vorkommendes) Beispiel: 16-Bit-Signal wurde mit Nullen auf 24 Bit aufgebläht. Da es an den 8 zusätzlichen Stellen nur eine einzige mögliche Kombination gibt, lässt sich das Kodieren auf die Verarbeitung der 16 Bit reduzieren. Und hier ist man wieder bei der ursprünglichen Aussage: Sind alle Kombinationen möglich, muss bei konstanter Bitrate die kodierte Form mindestens eine so hohe Bitrate wie die Quelle aufweisen, wodurch man wiederum keine Kompression hätte.

– 188.194.162.220 18:18, 14. Jan. 2010 (CET)

Qualität VBR

MP3-Standard: Warum soll eine VBR-Datei nach MP3-Standard in der Qualitätsstufe VBR-0 (höchstmögliche Qualität mit Zielbitrate ca. 245kbps) eine bessere Qualität bei geringerer Dateigröße erreichen, als eine CBR-Datei mit 320kbps? So weit mir bekannt, beträgt die höchstmögliche Datenrate nach MP3-Standard 320kbps. Was innerhalb des MP3-Standards ist an VBR bessere Qualität, wenn man die Datenmenge/ die Dateigröße vernachlässigt? (nicht signierter Beitrag von 88.74.50.58 (Diskussion) 17:11, 25. Mär. 2011 (CET))

• Wir bewegen uns hier in Richtung Relgion/Glauben/Aberglaube. So wie die 5000 Euro pro Meter teuren Boxenkabel. Mit Logik kommst du hier nicht weiter ... (nicht signierter Beitrag von 92.76.73.101 (Diskussion) 13:15, 3. Okt. 2011 (CEST))

VBR

hab hier meines Erachtens die beste Seite für eine Erklärung gefunden >> http://www.audiohq.de/index.php?showtopic=15 << --80.108.60.158 18:01, 15. Jun. 2012 (CEST)

Konstante Bitrate bei Streams

Hi, ich habe beim Durchlesen nicht verstanden, warum konstante Bitraten für Streams besser geeignet sind. Mir ist klar, dass bei Streams nach oben hin eine Grenze der Übertragungsgeschwindigkeit besteht. Aber wenn ich bei einer variablen Bitrate mal hin und wieder unter diese Grenze absinke, ist das doch kein Problem, oder? Dann hab ich halt etwas Bandbreite übrig, oder?

Besteht das Problem nicht eher darin, dass man bei einem Live-Streaming nicht genügend Zeit hat, um die Daten auf nötige (variable) Bitrate zu prüfen, bevor man sie weiterleitet? Oder wird die evtl. frei werdende Bandbreite dann von anderen Datenübertragungen "geklaut", so dass ich dann bei einer höheren Bitrate zu wenig habe?

Gruß, Stefan (Diskussion) 19:29, 4. Nov. 2012 (CET)

VBR Eingeschränkt geeignet für DivX und Xvid Videos?

Nach langjähriger Beobachtung und Tests führt VBR (nicht immer, aber gelegentlich bis oft) zu einer asynchronen Tonspur bei DivX und Xvid Videos. Die Asynchronität ist dabei nicht gleichmäßig, sondern wird mir der Zeit größer. So, als ob die Tonspur gestaucht wurde oder hier und da Teil gestaucht wurden. Eine Asynchronität bei CBR ist mir noch nie aufgefallen. Bei Musik fällt das nicht auf, da eine Stauchung von paar Millisekunden nicht wahrgenommen werden kann, schon gar nicht bei kurzen Musikstücken. Bei 90 Minuten kann meiner Beobachtung nach bei VBR schon 1 Sekunde am Ende fehlen. Wie gesagt, es sind meine Beobachtungen, die ich mit Tests überprüft habe. Wie es dazu kommt, weiß ich allerdings nicht. Ich weiß nur, dass es so ist. Allerdings hat sich anscheinend sonst niemand im Internet damit auseinandergesetzt (oder ich finde nichts). Somit trage ich das nicht in den Artikel ein. Falls jemand diesbezüglich etwas findet, könnte man u. U. etwas dazu schreiben. (nicht signierter Beitrag von 87.78.46.181 (Diskussion) 17:55, 8. Nov. 2013 (CET))