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: 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 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: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: 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: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:Hatte es schon zurückgezogen, aber Du warst mit dem Lesen offenbar schneller.... 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: Zja, ich rotiere auch ehrlichgetippt eben etwas. Eigentlich sollte ich ja schon in der Falle liegen, weil ich ja heute wieder raus muß, aber irgendwie wurmmt mich eben das Problem. 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: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:Das heißt, sind bits 2 UND 3 gesetzt (nach shiften: =3) =>layer 1,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; 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:Hmm, mein download ist inzwischen auch fertig... Warum bin ich noch online? 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: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. 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: 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: 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: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: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: Ja, hab mir das eben auch nochmal angesehn. Irgendwie liegt das Problem schon woanderst. Na, aber das wird schon. 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: 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 ) 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. ). 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: 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: 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: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:So kann das mit der deutschen Wirtschaft ja nix werden Zitat:Na so vereinfacht, wird das wohl kaum etwas. Hier mal der vereinfachte code aus einem funktionierendem Beispiel: code:Bitte die wahrscheinlich nicht ganz basic-konforme syntax zu entschuldigen. Mein letztes Basic-Programm liegt jahrhunderte zurück.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 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: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: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: 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 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... -- 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: 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. |