amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > MP3 VBR Laufzeit berechnen [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 5 6 7 [ - Beitrag schreiben - ]

05.08.2005, 00:54 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Poste doch mal den kompletten Code. Und sach dabei rasch, was Backslash in (M)Basic bedeutet.


Das / bringt bei einer Division einen Wert mit Rest, wärend eine Ganzzahldivision macht, was auch schneller ist. Das ist alles. :)

Ich schau mich nochmal im Internet um und versuch es zu Regeln. Denn Code bring ich auch gleich hier im Forum, der leider so zur Zeit quasi unbrauchbar ist.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:05 Uhr

Holger
Posts: 8116
Nutzer
Hmm, ich versuch den Code jetzt nochmal zu verstehen...

[ Dieser Beitrag wurde von Holger am 05.08.2005 um 01:06 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:11 Uhr

Ralf27
Posts: 2779
Nutzer
So, hier mal der Code, etwas abgemagert, aber der sollte so laufen, was er leider nicht macht:
code:
DEFINT a-z

REM $window
REM $errors
REM $lines
REM $library
REM $nodebug
REM $nobreak
REM $noevent
REM $nooverflow
REM $novarchecks
REM $noautodim
REM $noaddicon
REM $noarray
REM $nostack

REM $INCLUDE exec.bh
REM $INCLUDE dos.bh

LIBRARY OPEN "dos.library"
LIBRARY OPEN "exec.library"

DIM tbl(1,3,15):REM MPEG,Layer,Bitrate
FOR z=0 TO 1
 FOR y=3 TO 1 STEP -1:REM Layer 1-3 verdreht
  FOR x=1 TO 14
   READ tbl(z,y,x)
  NEXT
 NEXT
NEXT
REM MPEG2
DATA 8,16,24,32,64,80,56,64,128,160,112,128,256,320
DATA 32,48,56,64,80,96,112,128,160,192,224,256,320,384
DATA 32,64,96,128,160,192,224,256,288,320,352,384,416,448
REM MPEG1
DATA 32,64,96,128,160,192,224,256,288,320,352,384,416,448
DATA 32,48,56,64,80,96,112,128,160,192,224,256,320,384
DATA 32,40,48,56,64,80,96,112,128,160,192,224,256,320

 filename$="mp3:mp3/Badesalz/Zeitansage.mp3"

 Datei&=xOpen&(SADD(filename$+CHR$(0)),MODE_OLDFILE&)
 IF Datei&=0 THEN END

 PRINT"Lese"
 REM laenge ermitteln
 junk&=Seek&(Datei&,0,OFFSET_END&)
 Dateilaenge&=Seek&(Datei&,0,OFFSET_BEGINNING&)
 buf&=AllocMem&(Dateilaenge&,MEMF_PUBLIC&)
 IF buf& THEN rLen&=xRead&(Datei&,buf&,Dateilaenge&)
 junk&=xClose&(Datei&)
 IF buf&=0 THEN END
 
 Sec#=0

 PRINT"Durchsuche"
 FOR i&=0 TO Dateilaenge&-1
REM  IF INKEY$<>"" THEN i&=Dateilaenge&
  IF PEEK(buf&+i&)=255 THEN
   a=PEEK(buf&+i&+1)
   IF(a AND 240)=240 THEN
    REM Frame gefunden
    ID=(a AND 8) 8
    Layer=(a AND 6)2
    a=PEEK(buf&+i&+2)
    Bitrate=(a AND 240)16
REM    Frequenz=(a AND 12)4
REM    padding=(a AND 2)2
    i&=i&+4
    IF Layer=1 THEN
     i&=i&+768:REM 384 Sampels bei Layer1
     Sec#=Sec#+tbl(ID,Layer,Bitrate)/6.144
    ELSE
     i&=i&+2304:REM 1152 Sampel bei Layer2 und 3
     Sec#=Sec#+tbl(ID,Layer,Bitrate)/18.432
    END IF
   END IF
  END IF
 NEXT

Ende:
 FreeMem buf&,Dateilaenge&

 PRINT"Dauer:"sec#"Sec"


Man könnte da noch einiges mehr optimieren, aber erst mal sollte es laufen und eigentlich sollte es ja so laufen, was es aber nicht macht...
Ich bekomme z.b. falsche Werte bei ID,Layer,Bitrate, z.b. "illegale" Werte bei Bitrate, die nicht bei 0 oder 15 liegen sollten.
Im ersten Frame scheinen die zu stimmen, aber dann kommt nur noch Käse raus, egal ob ich jetzt die Weitersprungstory (i&=i&+768 bzw. i&=i&+2304) aktiviere oder nicht.

Was könnte da nur falsch sein.

Achja, sachen wie Checksumme im Header etc. lese ich nicht aus (um sie dann nach dem Header zu überspringen) oder auch ob Stereo oder nicht. Das ist ja erst mal Nebensache. Es sollte so schon laufen und die Frames schon finden, was aber so nicht so richtig läuft.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:16 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
code:
Layer=(a AND 6)2


Jeglicher mir bekannter Code sieht so aus:
code:
Layer=4- ((a AND 6)2)


mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:21 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Dann machen Zeilen wie

code:
ID=(a AND 8 )8

[code]und


padding=(a AND 2)2

[/code]

aber nicht viel Sinn, oder?


Eigentlich schon. Sollte das Bit 2 z.b. nach (a AND 2) gesetzt sein, dann kommt 2 raus. Wenn ich aber ein einfaches 1 oder 0 haben möchte, dann muß ich eine Division durchführen.

Z.b. ein (a and (128+64)) bzw. ein (a and 192) testet das Bit 7 und 6. Sollten beide Bits gesetzt sein, dann kommt eine 192 raus. Und wenn ich nur wenn beide Bits gesetzt sind eine 1 bekommen möchte, dann muß ich eine Ganzzahldivison machen, also xyz=(a AND 192)192.

Im Beispiel:
Bits 7-4 testen ob gesetzt:
IF (a AND 240)=240 THEN [...]
Will ich gar denn Inhalt der obern vier Bits (7-4) wissen:
xyz=(a AND 240)
Durch 16 muß ich dann halt auch noch teilen, wenn ich die oberen Bits "runterholen" möchte. Also die Bits 7-4 nach Bits 3-0.

Ich muß mir das auch nochmal ansehn mit dem Bitshift, aber leider steht im MBasic-Handbuch nicht mal drin das es sowas gibt!
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 05.08.2005 um 01:23 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:25 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Jeglicher mir bekannter Code sieht so aus:
code:
Layer=4- ((a AND 6)2)

.
Wie kommt denn das zustande?


--
http://www.alternativercomputerclub.de.vu

Edit:

> MPEG Layer (2 Bit)

> Diese beiden Bits geben Aufschluß darüber, ob es sich um MPEG-Audio Layer I, II oder III handelt. Der Wert 1 steht für Layer I, Wert 2 für Layer II und Wert 3 für Layer III.

Aus einer Doku, hab jetzt leider kein Link.
Wie kommt dann das mit 4-... Zustande? Insofern sollte doch der Layer doch direkt drin stehn. Also z.b. 1=1, 2=2, 3=3, 0=illegal. :)

[ Dieser Beitrag wurde von Ralf27 am 05.08.2005 um 01:36 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:27 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Eigentlich schon. Sollte das Bit 2 z.b. nach (a AND 2) gesetzt sein, dann kommt 2 raus. Wenn ich aber ein einfaches 1 oder 0 haben möchte, dann muß ich eine Division durchführen.

Hatte es schon zurückgezogen, aber Du warst mit dem Lesen offenbar schneller.... :rotate:

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:31 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
Eigentlich schon. Sollte das Bit 2 z.b. nach (a AND 2) gesetzt sein, dann kommt 2 raus. Wenn ich aber ein einfaches 1 oder 0 haben möchte, dann muß ich eine Division durchführen.

Hatte es schon zurückgezogen, aber Du warst mit dem Lesen offenbar schneller.... :rotate:

Zja, ich rotiere auch ehrlichgetippt eben etwas. :rotate: :lach:

Eigentlich sollte ich ja schon in der Falle liegen, weil ich ja heute wieder raus muß, aber irgendwie wurmmt mich eben das Problem. :D

Vielleicht hab ich das mit dem Layer auch falsch gemacht, aber irgendwie läuft da auch was mit dem Header falsch, ich kann mir das anderst nicht erklären.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:35 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Zitat:
Original von Holger:
Layer=4- ((a AND 6)2)

Wie kommt denn das zustande?
Ich hab mir nie Gedanken um das warum gemacht. Hatte es einfach so zur Kenntnis genommen, als ich die id3v2-lib nach Java portiert hatte. Sind halt keine Zahlen im eigentlichen Sinn. Auch in dem C Code, der in diesem Thread gepostet wurde, findet man:
code:
if(head[1]&2 && head[1]&4) id3tag->layer=1;
	else
	if(head[1]&4) id3tag->layer=2;
	else
	if(head[1]&2) id3tag->layer=3;

Das heißt, sind bits 2 UND 3 gesetzt (nach shiften: =3) =>layer 1,
ist bit 3 gesetzt (nach shiften: =2) =>layer 2,
ist bit 2 gesetzt (nach shiften: =1) =>layer 3,
sind beide Bits nicht gesetzt, ist das Ergebnis nicht gültig.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:39 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Eigentlich sollte ich ja schon in der Falle liegen, weil ich ja heute wieder raus muß, aber irgendwie wurmmt mich eben das Problem. :D

Hmm, mein download ist inzwischen auch fertig...
Warum bin ich noch online? 8o

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:42 Uhr

Ralf27
Posts: 2779
Nutzer
> MPEG Layer (2 Bit)

> Diese beiden Bits geben Aufschluß darüber, ob es sich um MPEG-Audio Layer I, II oder III handelt. Der Wert 1 steht für Layer I, Wert 2 für Layer II und Wert 3 für Layer III.

Aus einer Doku, hab jetzt leider kein Link.
Wie kommt dann das mit 4-... Zustande? Insofern sollte doch der Layer doch direkt drin stehn. Also z.b. 1=1, 2=2, 3=3, 0=illegal.

(Poste ich hier nochmal, hatte es oben nachträglich eingetragen)

Insofern bin ich jetzt etwas verwirrt. Bzw. hab es eben auch im Programm getestet, lief auch nicht richtig.

Hm, sollte aber leider wirklich so langsam in die Falle. Hab noch ein paar Stunden, dann geht es wieder rund.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:43 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Edit:
> MPEG Layer (2 Bit)

> Diese beiden Bits geben Aufschluß darüber, ob es sich um MPEG-Audio Layer I, II oder III handelt. Der Wert 1 steht für Layer I, Wert 2 für Layer II und Wert 3 für Layer III.

Aus einer Doku, hab jetzt leider kein Link.
Wie kommt dann das mit 4-... Zustande? Insofern sollte doch der Layer doch direkt drin stehn. Also z.b. 1=1, 2=2, 3=3, 0=illegal. :)
[ Dieser Beitrag wurde von Ralf27 am 05.08.2005 um 01:36 Uhr editiert. ]

Ah, ein Nachschlag. Hmm, wem vertraue ich jetzt mehr? Einer Doku, oder realem Code, der aus unterschiedlichen Quellen zu mir kam und funktioniert?
Da kann ich natürlich verstehen, daß man bei der Implementierung ziemlich ins Schleudern kommt. :nuke:

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:45 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
Eigentlich sollte ich ja schon in der Falle liegen, weil ich ja heute wieder raus muß, aber irgendwie wurmmt mich eben das Problem. :D

Hmm, mein download ist inzwischen auch fertig...
Warum bin ich noch online? 8o


:)

Ok, dann bis heute wieder zu einer "normaleren" Zeit. Kennst Du eine gute deutsche (hab ja das "Englisch"-Problem) Seite über denn MP3-Dateiaufbau? Hab da hier und da was gefunden, aber vielleicht gibt es ja noch irgendwo eine gute Seite.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:48 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Ah, ein Nachschlag. Hmm, wem vertraue ich jetzt mehr? Einer Doku, oder realem Code, der aus unterschiedlichen Quellen zu mir kam und funktioniert?
Da kann ich natürlich verstehen, daß man bei der Implementierung ziemlich ins Schleudern kommt. :nuke:


Also, wenn ich ehrlich bin dann würde ich viel mehr einem funktionierendem Code vertrauen. Hab da auch so meine Erfahrungen gemacht mit meinem BMP-Reader. Man kann halt im Internet einiges an Infos finden, aber leider auch einiges an falschen Infos...

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:49 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Kennst Du eine gute deutsche (hab ja das "Englisch"-Problem) Seite über denn MP3-Dateiaufbau?

Leider nein, habe nach so etwas auch noch nie gesucht, hab das "Englisch"-Problem nicht. Aber wir bekommen das auch so im Forum zusammen...
NB: Maiks original Basic Programm hat den Layer auch so interpretiert.
Zitat:
Ok, dann bis heute wieder zu einer "normaleren" Zeit.
Gute Nacht

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 01:52 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Leider nein, habe nach so etwas auch noch nie gesucht, hab das "Englisch"-Problem nicht. Aber wir bekommen das auch so im Forum zusammen...
NB: Maiks original Basic Programm hat den Layer auch so interpretiert.
Zitat:
Ok, dann bis heute wieder zu einer "normaleren" Zeit.
Gute Nacht

Ja, hab mir das eben auch nochmal angesehn. Irgendwie liegt das Problem schon woanderst. Na, aber das wird schon. 8)

Dir auch eine gute Nacht und Danke!
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 10:18 Uhr

MaikG
Posts: 5172
Nutzer
>Dies ist übrigens vorallem an de MaikG gerichtet. :) MaikG,
>erkennst du Teile vom Code? :)

Schon das ist der für mp3 ohne VBR? Der war nicht wirklich
zeitkritisch.
Bei dem anderen Code(Seite2) durchsuchst du aber nicht
mehr die ganze datei sondern versuchst es zu berechnen oder?

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 10:28 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
>Dies ist übrigens vorallem an de MaikG gerichtet. :) MaikG,
>erkennst du Teile vom Code? :)

Schon das ist der für mp3 ohne VBR? Der war nicht wirklich
zeitkritisch.
Bei dem anderen Code(Seite2) durchsuchst du aber nicht
mehr die ganze datei sondern versuchst es zu berechnen oder?


So, ich hab mal endlich etwas Zeit in der Firma und mich mal etwas schlauer gemacht:
Also, auf vielen deutschen MP3-Dateiinfoseiten steht ein haufen Käse, aber wirklich.
z.b. steht auf deutschen Seiten das Layer1=Bit1, Layer2=Bit2, Layer3=Bit3... ist genau anderstherum. Oder auch die Framelängenstory. Ich dachte erst die Frames wären in einer festen länge, aber das stimmt natürlich nicht. Die Samples(!) sind fest vorgegeben, aber das hab ich erst herrausgefunden als ich auf einer englischen(!) eingedeutschen(Google :P ) Seite kurz mal reingelesen habe.
Und noch so ein paar Kleinigkeiten...

Achja, das Programm hier durchsucht die ganze Datei, aber der Code der hier steht läuft nicht richtig, bzw. die Framelaenge wird total falsch berechnet.
Jetzt stimmt zwar ca. die Framelaenge (ohne Padding, ohne Checksumme, die übrigens 16Bit und nicht 32Bit lang ist, wie auf ein paar dummen deutschen Seiten beschrieben. Da wird wohl einiges durchgewürfelt. :lach: ).

Aber ich hab noch das Problem das die Frameheader nicht richtig gefunden werden. So bekomme ich einen ganz schönen Datenmüll zusammen. Der erste Header scheint aber zu stimmen.

Aber es scheint sich schon zu zeigen das man so die Spielzeitdauer wirklich innerhalb einer Sekunde herrausfinden kann. Und das könnte man dann vermutlich auch mit Seek machen ohne die Datei komplett zu laden.
Allerdings verstehe ich wirklich nicht wieso er die Header nicht richtig findet, bzw. wieso so ein Datenmüll rauskommt. Hab übrigens gestern noch etwas den Code modifiziert.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 10:33 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
Schon das ist der für mp3 ohne VBR? Der war nicht wirklich
zeitkritisch.
Bei dem anderen Code(Seite2) durchsuchst du aber nicht
mehr die ganze datei sondern versuchst es zu berechnen oder?


Der ist für VBR gedachte. Aber nur für MPEG1 oder MPEG2 von Layer1 bis Layer3. Bzw. VBR oder kein VBR. Ist dabei eigentlich egal.

Hab aber eben einige Infos gefunden, die so leider falsch auf deutschen Seiten stehn. Muß ich mir heute Abend mal genauer ansehn.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 10:48 Uhr

thomas
Posts: 7718
Nutzer
Zitat:
Original von Holger:
Und sach dabei rasch, was Backslash in (M)Basic bedeutet.


Das kann man doch aus dem Kontext erkennen: ganzzahlige Division.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 11:50 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von thomas:
Das kann man doch aus dem Kontext erkennen: ganzzahlige Division.

Nö, kann man nicht. Und es ist sowieso nicht sinnvoll, etwas aus einem Programmcode erraten zu wollen, von dem bereits gesagt wurde, daß er nicht das tut, was er soll.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 12:01 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
So, ich hab mal endlich etwas Zeit in der Firma und mich mal etwas schlauer gemacht:

So kann das mit der deutschen Wirtschaft ja nix werden :lach:
Zitat:
Achja, das Programm hier durchsucht die ganze Datei, aber der Code der hier steht läuft nicht richtig, bzw. die Framelaenge wird total falsch berechnet.
Jetzt stimmt zwar ca. die Framelaenge (ohne Padding, ohne Checksumme,...).

Na so vereinfacht, wird das wohl kaum etwas. Hier mal der vereinfachte code aus einem funktionierendem Beispiel:
code:
IF Layer=1 THEN
  framesize = 4 * (12 * bitrate / frequency + padding_bit)
ELSE IF Layer=2 THEN
  framesize = 144 * bitrate / frequency + padding_bit
ELSE IF Layer=3 THEN
  IF version = MPEGVERSION_2_5
    framesize = 144 * bitrate / frequency + padding_bit
  ELSE
    framesize = 72000 * bitrate / frequency + padding_bit
  ENDIF
ENDIF

Bitte die wahrscheinlich nicht ganz basic-konforme syntax zu entschuldigen. Mein letztes Basic-Programm liegt jahrhunderte zurück.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 05.08.2005 um 12:02 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 12:07 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Ralf27:
Aber es scheint sich schon zu zeigen das man so die Spielzeitdauer wirklich innerhalb einer Sekunde herrausfinden kann. Und das könnte man dann vermutlich auch mit Seek machen ohne die Datei komplett zu laden.

Seek lohnt sich nur, wenn man mehr als einen Block überspringt. Im Falle von zeitgemäßen Festplatten müßte es auch deutlich mehr als ein Block sein.
Deutlich mehr wäre herauszuholen, wenn man das Einlesen asynchron ausführt. Ist in einem Basic-Programm vermutlich sehr kompliziert zu machen...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 14:20 Uhr

MaikG
Posts: 5172
Nutzer
Mh, ganz versteh ich das nicht.

Ich hab einige teile jetzt übernommen, da läuft aber
tatsächlich was schief.


Wenn ich das richtig verstehe ist

Bitrate=(a AND 240)16

identisch zu

Bitrate=a16

oder Bitrate=INT(a/16)

?

und mit AND Maskiert man irgendwie Bits?

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 16:02 Uhr

Holger
Posts: 8116
Nutzer
In meinem Code oben ist ein Fehler. Statt
IF version = MPEGVERSION_2_5
muß es
IF version = MPEGVERSION_1
heißen. Hatte das aus der ID3v2-lib übernommen und die ist offenbar falsch. Komischerweise befindet sich im original-code genau an der Stelle ein Kommentar, der so erklärt, wie es richtig wäre.
Der Teil wurde in meiner eigenen Anwendung offenbar nicht benutzt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 16:07 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:
Wenn ich das richtig verstehe ist

Bitrate=(a AND 240)16

identisch zu

Bitrate=a16

oder Bitrate=INT(a/16)

?

und mit AND Maskiert man irgendwie Bits?

Wenn man ein einzelnes byte betrachtet, werden durch die Maskierung nur die unteren bits gelöscht, was durch die Division durch 16 auch passiert.
Problematisch wird es dann, wenn das byte als vorzeichenbehaftet interpretiert und die Rechnung nicht in byte, sondern int durchgeführt wird. Wie genau dieses Basic an der Stelle vorgeht, kann ich nicht sagen. Wenn das Ergebnis von peek zwischen 0 und 255 liegt, ist es genau so, wie Du beschreibst. Liegt es zwischen -128 und +127, brauchst Du AND.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 18:50 Uhr

MaikG
Posts: 5172
Nutzer
@Holger

Das schlimme ist das nix davon Funktioniert sobald
die Binär-Zahl weniger als 8 Stellen hat, was jedoch
der Fall ist wenn es führende nullen gibt.
Deshalb werden in mein Programm Nullen dazugefügt,
was so nur mit Strings geht.
Deshalb liefert Ralf's Programm andere Werte.

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 19:50 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von MaikG:
@Holger

Das schlimme ist das nix davon Funktioniert sobald
die Binär-Zahl weniger als 8 Stellen hat, was jedoch
der Fall ist wenn es führende nullen gibt.
Deshalb werden in mein Programm Nullen dazugefügt,
was so nur mit Strings geht.
Deshalb liefert Ralf's Programm andere Werte.


Nun, da kann ich dir widersprechen. Ich benutze ja keine Strings um eine Zahl darzustellen. Kleines Beispiel:

Wenn ich in einem Byte die Zahl 0 speicher, dann kann ich auch das oberste Bit abfragen und das geht auch mit dem wie ich es oben gemacht habe. In der Sache bin ich mir ganz sicher. Außerdem werden die Integerzahlen bei Basic in 16Bit gespeichert, also -32767 bis 32768(ca. +-1 :) ).

Also kann ich auch mit z.b. IF (a AND 240)=240 THEN [...] wirklich darauf prüfen ob die oberen 4Bits gesetz sind und da ist es egal was für eine Zahl es ist. Wenn es 0 ist, dann sind halt die oberen Bits nicht gesetzt und die Bedingung ist nicht erfüllt.

Ich hab aber heute bei der "Infos für die Arbeiter"-Aktion :lach: in der Firma etwas Wissen eingefangen und mitbekommen das ich sozusagen faule Deutsche Dokus in Händen hatte, wie z.b. die Layerstory.

Ich mach mich später nochmal dran, muß noch was erledigen. Es gibt immer was zu tun... :D
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 20:35 Uhr

Ralf27
Posts: 2779
Nutzer
Hier nochmal der Code:

code:
DEFINT a-z

REM $window
REM $errors
REM $lines
REM $library
REM $nodebug
REM $nobreak
REM $noevent
REM $nooverflow
REM $novarchecks
REM $noautodim
REM $noaddicon
REM $noarray
REM $nostack

REM $INCLUDE exec.bh
REM $INCLUDE dos.bh

LIBRARY OPEN "dos.library"
LIBRARY OPEN "exec.library"

DIM tbl&(1,4,15):REM MPEG,Layer,Bitrate
FOR z=0 TO 1
 FOR y=1 TO 3
  FOR x=1 TO 14
   READ a&
   tbl&(z,y,x)=a&*1000:REM kHz, also mal 1000
  NEXT
 NEXT
NEXT
REM MPEG2
DATA 32,64,96,128,160,192,224,256,288,320,352,384,416,448
DATA 32,48,56,64,80,96,112,128,160,192,224,256,320,384
DATA 8,16,24,32,64,80,56,64,128,160,112,128,256,320
REM MPEG1
DATA 32,40,48,56,64,80,96,112,128,160,192,224,256,320
DATA 32,48,56,64,80,96,112,128,160,192,224,256,320,384
DATA 32,64,96,128,160,192,224,256,288,320,352,384,416,448
DIM Freq&(1,3):REM MPEG,Wert
FOR z=0 TO 1
 FOR x=0 TO 2
  READ Freq&(z,x)
 NEXT
NEXT

DATA 44100,48000,32000
DATA 22050,24000,16000

 filename$="mp3:mp3/Badesalz/Zeitansage.mp3"

 Datei&=xOpen&(SADD(filename$+CHR$(0)),MODE_OLDFILE&)
 IF Datei&=0 THEN END

 PRINT "Lese"
 REM laenge ermitteln
 junk&=Seek&(Datei&,0,OFFSET_END&)
 Dateilaenge&=Seek&(Datei&,0,OFFSET_BEGINNING&)
 buf&=AllocMem&(Dateilaenge&,MEMF_PUBLIC&)
 IF buf& THEN rLen&=xRead&(Datei&,buf&,Dateilaenge&)
 junk&=xClose&(Datei&)
 IF buf&=0 THEN END
 
 Sec#=0

 PRINT"Durchsuche"
 FOR i&=0 TO Dateilaenge&-1
  IF PEEK(buf&+i&)=255 THEN
   a=PEEK(buf&+i&+1)
   IF(a AND 240)=240 THEN
    REM Frame gefunden
    ID=(a AND 8 )8 :REM Zja, hier macht mir als das Forum aus dem 8 ) ein Smilie :) 
    Layer=4-(a AND 6)2
REM    Check=(a AND 1)
    a=PEEK(buf&+i&+2)
    Bitrate&=tbl&(ID,Layer,(a AND 240)16)
    Frequenz&=Freq&(ID,(a AND 12)4)
    Padding=(a AND 2)2
    i&=i&+4
REM    IF Check THEN i&=i&+2
    IF Layer=1 THEN
REM     i&=i&+(12*BitRate&/Frequenz&)*4:REM 384 Samples bei Layer1
REM     Sec#=Sec#+BitRate&/Frequenz&
    ELSE
REM     i&=i&+144*BitRate&/Frequenz&:REM 1152 Samples bei Layer2 und 3
REM     Sec#=Sec#+BitRate&/Frequenz&
    END IF
   END IF
  END IF
 NEXT

Ende:
 FreeMem buf&,Dateilaenge&

 PRINT"Dauer:"sec#"Sec"


Schon die "Datenerfassung" im Frame ist fehlerhaft, bzw. schon das erkennen der Frames (Vermutung). Ich hab deswegen mal ein paar REMs vor die entsprechenen Zeilen gelegt die sonst Unfug machen.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 05.08.2005 um 20:39 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

05.08.2005, 20:38 Uhr

Ralf27
Posts: 2779
Nutzer
Zitat:
Original von Holger:
Seek lohnt sich nur, wenn man mehr als einen Block überspringt. Im Falle von zeitgemäßen Festplatten müßte es auch deutlich mehr als ein Block sein.
Deutlich mehr wäre herauszuholen, wenn man das Einlesen asynchron ausführt. Ist in einem Basic-Programm vermutlich sehr kompliziert zu machen...


Ich vermute mal das es ganz so wäre wie in C. Ich vermute du sprichst auf HOOKs an? Ich hab damit wirklich noch nie was gemacht und für mich sind das eher Schreckgespenster. :)

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 4 5 6 7 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > MP3 VBR Laufzeit berechnen [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.