Re: Warum gibt es XMMS2?
Am Freitag, 11. Juli 2008 schrieb Michelle Konzack:
> Am 2008-07-10 18:37:47, schrieb Markus Schulz:
> > http://www.fh-jena.de/contrib/fb/et/personal/ansorg/mp3/mp3_2_res.h
> >tm
> >
> > Wo genau im Frameheader steckt da diese Information drin?
>
> Ich lann das lame Paket wegen Sarge nicht installieren... Steht
> aber dort irgendwo in der Dokumentation
>
> > > Sieh Dir die Dokumentation zu "lame" an, dort ist die
> > > Option beschrieben. Abgesehen davon gibt es die Option AUCH in
> > > Ogg Vorbis.
> >
> > Bitte mal nen Anker, wo genau das stehen soll.
> >
> > Ich höre pausenlos mp3 via http (ich höre quasi keine lokalen mehr)
> > und bisher gibt es nur Probleme die durch den Player verursacht
> > werden (kein http-range), das mp3 spielte dabei bisher absolut
> > keine Rolle.
>
> Ach ja? Und wie bekommst Du die mp3-Infos? Die stehen am ende
> der Datei, sprich, wenn Du auf einen mp3-Link klickste weiste
die braucht der Player nicht unbedingt, die Laufzeit wird aus der
Byte-Größe (vom Apache mit übertragen) und den bereits erhaltenen
Frames (daher puffert er auch immer) berechnet, deshalb stimmt das in
den meisten Fällen auch nicht exakt (kann ich durch langjährige
Beobachtung auch bestätigen) oder ist bei VBR sogar ziemlich daneben.
Spulen ist dann natürlich auch nur relativ ungenau möglich.
Desweiteren besteht für den Player auch die Möglichkeit die letzten
Bytes der Datei als erstes zu holen, dafür ist die Range Extension ja
da, dafür müsste man aber einen Blick in den Quellcode von mplayer und
co. werfen.
> Wenn Du per HTTP-RANGE ein mp3 runterlädst, weis Dein layer auch
> nicht, wieviel minuten Du übersprungen hast, weshalb Dein mp3-Payer
> mindestens einen vollständigen Frame benötigt um die Gesamtspielzeit
> des mp3, die Gesamtlänge in Bytes, sowie die Framenummer, den Begin
> (in milisekunden) und ein paar andere infos liefert.
genau deshalb puffert er ja (einstellbar) viele KBytes vor dem
Abspielen.
> Nur habe ich keine infos gefunden, wie groß ein solcher Frame ist.
Zitat von obiger Quelle:
**********************
Jedes Frame enthält eine feste Anzahl von Abtastwerten (Samples). Bei
Level 3 sind dies 1152 Abtastwerte pro Frame (32 Subbänder x 36
Samples). Ein Frame besteht aus einem Header, einem Prüfsummencheck,
den eigentlichen Audiodaten sowie unter Umständen einem so genannten
Bit-Reservoir. Ein solches Reservoir entsteht, wenn sich die Samples
innerhalb des Frames so komprimieren lassen, dass nicht die komplette
theoretische Bit-Anzahl eines Frames benötigt wird.
**********************
--
Markus Schulz
Aber meiner persönlichen Meinung nach ist ein Sid an 355 Tagen im Jahr
mehr "stable" als z.B. ein Suse "fertig" in den Läden steht.(Joerg
Rossdeutscher)
Reply to: