Hallo!
Kannst Du mal bitte sagen wie ich mir die Dateigröße dann vorstellen kann? Ich hab da noch nicht so viel Erfahrung und hab halt mp3 und ogg mal erzeugt und komme da bei ner stunde auf 100MB mp3 . da bin ich dann hellhörig geworden und durch eure posts hier schon ne ganze Menge weiter, aber es fehlt noch so ne kleine Ecke für das große Ganze 
danke
Die kannst du auf http://www.dasgrundrauschen.de/ genau nachgucken 
Oder näherungsweise in einer Auphonic Produktionen (oder’nem Preset) unter Output Files > Bitrate, nachdem du eines der Audioformate eingestellt hast.
1 „Gefällt mir“
Wer reine Sprachpodcasts mit 128kBit/s oder mehr versendet, sollte meiner Meinung nach auch die Verwendung von Goldkabeln ins Auge fassen.
Etwas Hintergrund zu verlustbehafteter Audio-Kodierung und wie und wieso ihr euer Encoding und eure Audiopipeline speziell für MP3 genau ansehen solltet:
Die Kompression basiert grundsätzlich darauf, dass das Ohr nicht die gesamte Hörinformation gleich bewertet, sondern leise Frequenzbestandteile (aufgelöst in Gruppen) ohne subjektiven Verlust weggelassen werden können. Damit die zunächst als “Spannungsverlauf” gespeicherte Musik (wav oder flac-Format) überhaupt so verarbeitet werden kann, wird sie mit der Fouriertransformation (denkbar wären auch Wavelets) in Frequenzbestandteile zerlegt. Da werden dann psychoakustische Heuristiken angewendet, um den Beitrag zu quantisieren, also mit weniger Auflösung zu speichern, oder ganz auf 0 zu setzen. Da die Periodenlänge von Tönen mit hohen Frequenzen kürzer sind, und daher viel mehr in einem Zeitabschnitt auftreten, liegt es in der Natur der Sache, dass Geräusche mit hohen Frequenzen im Verhältnis viel mehr Information beinhalten.
Es bringt also extrem viel für die Kompression, wenn Signale eine begrenzte Bandbreite haben, also nur in bestimmten Frequenzbereichen einen Beitrag leisten, und möglichst wenig hohe Frequenzbestandteile besitzen. Entsprechend ist Rauschen der totale Kompressionskiller, da es im schlimmsten und idealen Fall aus allen Frequenzen besteht.
Natürlich kann man theoretisch auch dadurch sparen, dass man nur einen Kanal (also Mono) versendet als zwei Kanäle zu verwenden (Stereo). Die Verwendung von zwei gleichberechtigten und unabhängigen Kanälen in fast allen Fällen (außer z.B. Zwei-Kanal-Ton in zwei unterschiedlichen Sprachen) unsinnig ist, und stattdessen das Mischsignal in hoher Datenrate und die Unterschiede in geringerer Datenrate (siehe auch Intensitätsstereofonie) übertragen werden sollten.
Bei wechselnden Charakteristiken im Tonsignal macht es auch Sinn die Menge der übersendeten Daten zu verändern- also variable Bitraten zu verwenden. Neben der Strategie “feste Bitraten” zu benutzen (CBR- constant bitrate), gibt es auch “gemittelte Bitraten” (ABR- averaged bitrate) und “qualitätsorientierte Bitraten” (VBR- variable bitrates). Bei CBR ist die Bitrate immer konstant, bei ABR werden höhere und kleinere Bitraten je nach Anforderungen toleriert, aber eine feste durchschnittliche Bitrate garantiert, bei VBR wird die Bitrate rein durch “Anforderungen” skaliert definiert. (Und wie die “Anforderungen” oder die “Qualität” sinnvoll gemessen werden kann, und wie man darauf durch ein Regelungssystem reagiert- womöglich mit Multi-pass Encoding- ist nochmal ein ganz eigenes Thema…)
Was bedeutet das alles für unsere Audiopipeline und die Kompressionsparameter?
Beim Einzug von MP3 gab es den Goldstandard von konstanten 128kBit/s, der uns quasi “CD-Qualität” versprach. Die Kompression um das etwa 10-fache war beeindruckend, aber oft konnte man Unterschiede feststellen: Gerade am Anfang wurde noch viel bei den psychoakustischen Modellen experimentiert, oder die Aufteilung des Stereosignals erfolgte in zwei getrennten Kanälen. Eine einfache Möglichkeit mehr “Qualität” bei geringerer “Datenmenge” zu erzeugen, waren Tiefpassfilter. Dadurch, dass man schon vorher hohe Frequenzen herausfiltert (oder eine geringere Abtastrate als 44kHz zu verwenden), hat man die schwierigsten Bestandteile schon vor Kompression gelöscht.
Mit verschiedenen Hörtests wurden dann Werte gefunden, die für typische Anwendungen (insb. kontinuierliche Musik) für jeweils bestimmte Bitraten die subjektiv beste Abbildung des Signals für viele Menschen liefert. Für spezielle Anwendungen können aber ganz andere Werte sinnvoll sein, und aus meiner Sicht ist dies bei Sprachpodcasts ganz sicher der Fall:
- Sprache ist nie kontinuierlich- ihr macht (hoffentlich) Pausen beim Reden.
- Es spricht meisstens nur eine Person aus einer Richtung.
- Stimmen sind stark beschränkt in ihrer Bandbreite.
Das sind riesige Vorteile für die Kompression, die ihr beispielsweise mit folgenden Dingen kaputt machen könnt:
- Musik oder Atmo in den Hintergrund legen
- Musik oder andere Geräusche einspielen
- Rauschen in Stille nicht ausblenden
- Generell Störgeräusche zulassen (z.B. im oben zitierten LS001 das Brummen und Rauschen)
- Schall auf zweitem Kanal aufnehmen (fehlendes Crossgating/Übersprechen)
- Unterschiedliche Intensität der Sprechenden auf Kanälen zulassen (veränderliches Panorama)
Die ersten beiden Dinge sind teilweise ja gewollt oder erwünscht. Dann wird man über die Standardwerte nicht herumkommen und sollte mit hohen Bitraten kodieren (zB @Explikator, @Dennis_SciPie, @modnerd). In allen anderen Fällen kann man mit speziellen Codecs (wie Opus) aber auch definitiv aus MP3 noch viel mehr herauskitzeln, so dass spezielle Codecs in vielen Fällen keine großen Vorteile mehr besitzen.
Wenn die Audiopipeline in der Stille wirklich das Rauschen herausblendet, so kann man hier sehr viel gewinnen: Für Stille braucht man keine 128kBit/s, sondern da reichen 32kBit/s, das ist das Minimum bei MP3. Damit der Encoder das realisieren kann, sollte man auf jeden Fall CBR vermeiden und auf ABR oder VBR wechseln. Ja, es gibt noch sehr, sehr alte Player, die mit veränderlichen Bitraten Probleme haben. Werft sie weg. Wir haben 2015.
Generell ist Rauschen oder anderes Störgeräusch der Killer schlechthin- gute Mikros mit festem Abstand zum Sprecher und symmetrische Übertragung bringt euch auch wegen der Kompression einen großen Qualitätsgewinn.
Verwendet Crossgating gegen das Übersprechen und Hall, und pegelt Personen fest auf eine Panoramastellung zwischen Links und Rechts. Dann habt ihr die Vorteile der besseren Personenauflösung durch Stereo ohne Qualitätsverluste oder höhere Bitraten- siehe auch die Diskussion zu Stereo/Mono. Insgesamt unterscheidet sich hier Sprach-Stereo völlig von Musik-Stereo: Musik braucht durch unterschiedliche Tonquellen an unterschiedlichen Orten wirklich zwei Kanäle, bei Sprache ist es nur eine Quelle an festem Ort und so wird nur diese (bei Stereo) kodiert. Wenn man das richtig macht, so erhält man schon alleine deshalb mit 80kBit/s bei Sprache lässig die Qualität von 128kBit/s bei Musik. (Auch hier tut sich ein weites Feld auf: Eigentlich will man Personen nicht nur mit “Pegel” in Stereo verorten, sondern auch Laufzeitunterschiede zulassen, aber das können die Encoder nicht “erkennen” und macht die Kompression kaputt.)
Auch wenn ihr das alles befolgt, hört ihr sicher sofort einen Unterschied, wenn ihr jetzt mit beispielsweise 64kBit/s statt 128kBit/s eure Podcasts kodiert. Das liegt zum ganz großen Teil am Tiefpassfilter, der bei Musik mit hohen Bandbreiten ganz sicher Vorteile hat, aber bei schmalbandiger Sprache schon im Vorfeld ohne Not das Signal nicht nur verfälscht, sondern richtig kaputt gemacht.
Bei lame ist der Tiefpassfilter bei 192kBit/s bei 19.2kHz, bei 128kBit/s bei 17kHz, bei 96kBit/s bei 15.5kHz (mit resampling auf 32kHz), bei 64kBit/s bei 11.2kHz (mit resampling auf 24kHz). Da könnt ihr euch die Aufnahme bei 44.1kHz Samplefrequenz sparen, wenn der Encoder gleich mal jedes zweite Byte einfach wegwirft, noch lange bevor das psychoakustische Modell mal eine Chance hat, eine sinnvollere Auswahl zu treffen: Das Resultat klingt dumpf.
Glücklicherweise kann man das ausschalten, und voilá- plötzlich klingt auch durchschnittlich 64kBit/s für Sprachpocasts ganz passabel, wenn man auch die anderen Punkte oben beachtet. Meiner Erfahrung nach geht es aber nicht wirklich tiefer mit MP3- es hängt auch von den Stimmen ab. Da es ja Menschen mit höheren Stimmlagen gibt, wie auch bei unserem Podcast, sollte man die Bitrate nicht fest auf einen Wert wie 64kBit/s (per ABR) festlegen, sondern die Bitrate von den Anforderungen abhängig machen, also VBR verwenden.
Wir verwenden seit einiger Zeit und Optimierung folgendes MP3-Encoding
lame -V8.5 -q0 --lowpass 22050 --resample 44100
und haben in den letzten Folgen (bei >99% MS-Encoding durch Crossgating) diese Bitraten erreicht: Folge 63 hat gesamt 67kBit/s, Folge 64 hat 69kBit/s und Folge 65 wieder 67kBit/s. Folgen mit viel Atmo oder Hall erhalten automatisch mehr- Folge 56 von der Gulaschprogrammiernacht hat 74kBit/s. Das ganze in Stereo und bisher ohne jeglichen negativen Kommentar zur Qualität- ganz im Gegenteil.
Your milage may vary, aber wir kommen sehr gut mit den niedrigen Bitraten zurecht und brauchen daher keine weiteren Feeds. Und man kann uns in vielen Teilen der Edge-Hölle noch streamen. =)
5 „Gefällt mir“
Magst du das nochmal tl:dr mäßig kurz zusammenfassen? 
Schöne Einführung!
Jedoch listest du hier deine Bitratenempfehlungen natürlich für VBR, mit CBR MP3 klingt 64k meist nicht wirklich gut (kommt natürlich auch aufs Material drauf an).
Der entscheidende Punkt ist halt dieser:
Das ist leider IMHO immer noch nicht so einfach. Ja, es gibt mittlerweile wirklich extrem wenig Player die kein VBR können, das können fast alle.
Aber: mit VBR haben wirklich viele Player Probleme wenn es um seeken usw. geht, auch z.B. webplayer in browsern, podcasting apps etc. Da gibt es leider immer wieder komische Effekte.
Wir könnten dan ja gerne nochmal eine umfassendere Versuchsreihe machen. Wir (bei Auphonic) haben unser MP3 mal auf VBR standardmäßig umgestellt gehabt und viele Problemberichte gehabt.
Aber das ist nun auch schon ca. 1,5 Jahre her, vielleicht hat sich da ja was verbessert. Würde gerne alles auf VBR MP3 machen, das klingt natürlich viel besser
Ich persönlich sehe MP3 CBR eher als Fallback Format an, das überall gut spielt.
Zusätzlich kann man bei Bedarf ja modernere Formate nehmen: MP3 VBR, AAC, Opus, etc.
Aber bei diesem Vergleich ist halt AAC schon viel besser als MP3 VBR und wird auch von eigentlich allen Geräten unterstützt (auch keine mir bekannten Probleme bei seeken usw.) - bzw. Opus ist natürlich auch viel besser aber wird leider noch nicht von allen unterstützt …
2 „Gefällt mir“
Ja, natürlich sollten man variable Bitraten und kein altertümliches CBR bei MP3 verwenden- da hast du meine Empfehlung ganz richtig verstanden! =)
Wenn man aber ohnehin mehrere Feeds macht, ist die Frage, was man als Standard verwendet. Der Hauptfeed für die 99% der Nutzer sollte breit kompatibel sein, das Format sinnvoll nutzen und keine Bandbreite verschwenden. Wir haben bei uns als Ausweichlösung Ogg Vorbis für Firefox-Browser.
Für den Rest kann man ja dann Sonderfeeds bereitstellen- und das ist was anderes als den 64kBit-Feed als Sonderlösung dazustellen.
Ich würde bei euch aber nicht den Standard auf meinen Vorschlag umstellen- euch verwenden viele verschiedene Formate, und mein Text oben bezieht sich eben nur auf die reinen Sprachpodcasts. Und die Unterstützung von Kapitelmarken ist auch nochmal ein ganz anderes Thema. Aber als optimierende Option für Sprachpodcasts wäre ein angepasstes Encoding doch ganz interessant.
Wie geht ihr denn mit den Lowpass-Filtern um? Übernehmt ihr die Musik-Presets?
2 „Gefällt mir“
Sammeln wir noch? Ich nutze für “Wie geht eigentlich…?” AAC (weil persönlicher Apple Bias und offensichtliche Vorteile bei Dateigröße/Tonqualität) und MP3 (um möglichst viele Hörer mitzunehmen) wie sie aus Auphonic rausfallen (weil ich da sane defaults annehmen kann). Beides in Mono, weil ich oft selbst mit nur einem Hörer höre und mich viel über Stereo-Podcasts aufrege. (Wie gesagt, andere Debatte.)
Ich denke darüber nach auch noch OGG oder Opus anzubieten, muss mich da aber nochmal genauer über Vor- und Nachteile der jeweiligen Formate informieren und dann mal sehen, ob es überhaupt Bedarf dafür gibt.
1 „Gefällt mir“