|
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 - ] |
| Erste 1 2 3 4 5 -6- 7 | [ - Beitrag schreiben - ] |
|
09.08.2005, 00:50 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wieso ein komplett neues Programm? Die String-Arithmetik wurde durch normale Berechnung ersetzt, was für eine Berechnung im sinnvollen zeitlichen Rahmen unumgänglich ist. Da Dein Programm zu 90% genau daraus bestand, haben sich natürlich 90% des Programms geändert. Aber was soll's, Dein Programm geht nach Deiner eigenen Aussage bei 1/3 Deiner mp3's nicht und enthält eine Reihe unberücksichtigter Fälle. Ich versuche die Probleme in dem Programm zu beheben, in denen es um Minuten abweicht oder abstürzt, weil Header fehlerhaft interpretiert werden, und Du redest von nicht-funktionieren, wenn das Ergebnis um eine Sekunde abweicht, verstehe ich das richtig? nfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 09:51 Uhr MaikG Posts: 5172 Nutzer |
>Natürlich, das ist doch der Sinn der Sache. Um bei einer >ganzzahligen Anzahl von byte/frame auf eine definierte >Bitrate zu kommen, wechselt die Anzahl zwischen n und n+1, >so daß es in der Gesamtheit stimmt. Also ich hab es so das Padding dem 1.Frameheader bei den Folgenden Frames entsprechen muss, trotztdem stimmt das ergebniss. >Wieso ein komplett neues Programm? Die String-Arithmetik >wurde durch normale Berechnung ersetzt, was für eine >Berechnung im sinnvollen zeitlichen Rahmen unumgänglich >ist. Inzwischen hab ich hier auch keine Strings mehr, ist trozdem lahm. >Da Dein Programm zu 90% genau daraus bestand, haben sich >natürlich 90% des Programms geändert. Aus die weise verstehe ich die Funktion nicht mehr so ganz und kann das daher auch nicht zum laufen bringen. >Aber was soll's, Dein Programm geht nach Deiner eigenen >Aussage bei 1/3 Deiner mp3's nicht und enthält eine Reihe >unberücksichtigter Fälle. Mein Programm macht Eine Mp3 VBR Datei von 4 MP3 Dateien nicht, nicht 33% nur Eine einzelne mp3 Datei. Dateien ohne VBR Funktionieren 100%ig. >Ich versuche die Probleme in dem Programm zu beheben, in >denen es um Minuten abweicht oder abstürzt, weil Header >fehlerhaft interpretiert werden, und Du redest von >nicht-funktionieren, wenn das Ergebnis um eine Sekunde >abweicht, verstehe ich das richtig? Nein, meins stürzt nicht ab und wich bis gestern um weniger als eine Sekunde ab. Ralf hat mir da noch was korregiert und jetzt weicht es gar nicht mehr ab. Ist halt nur so langsam. 28s pro VBR Mp3 durchschnittlich. Die ohne VBR rasen natürlich durch. [ Dieser Beitrag wurde von MaikG am 09.08.2005 um 09:57 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 11:10 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: An einem Punkt könnte man dein Programm rasant beschleunigen: Bei der Framegrößenberechnung, die bei dir im aktuellen Programm quasi nicht vorhanden ist. Die vorhandene Programmzeile lief deswegen eigentlich nie richtig, weil die Bitrate nicht mal 1000 genommen wurde, sodas er einen Frame tausend mal zu groß berechnet hat. Ich wollte aber nicht zuviel (eigentlich hab ich fast nix verändert) ändern, da es bei dir wohl läuft. Bei mir hat es einige Fehler ausgeworfen. Da haben wir wohl unsere Programme auf die jeweilige MP3-Sammlung optimiert.  -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 12:57 Uhr MaikG Posts: 5172 Nutzer |
>An einem Punkt könnte man dein Programm rasant >beschleunigen: Bei der Framegrößenberechnung, die bei dir >im aktuellen Programm quasi nicht vorhanden ist. Wenn ich das richtig sehe hast du doch eine Frameberechnung eingebaut. Die dann i& erhöht, daher ein Stück überspringt oder nicht? [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 22:35 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Aber ungetestet. Irgendwie sollte es so laufen, aber irgendwie... Bei Dir scheint es ja zu laufen, bei mir hat das Programm Fehler "geworfen". Ich hab auch mal versucht im Internet Infos über Xing zu bekommen, also denn Aufbau, wurde aber nicht fündig. Du scheinst da Dokus zu haben? Außerdem hab ich auf einigen Seiten gelesen das es auch Xing-Tags geben soll die nicht ganz koscha sind? -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 22:49 Uhr Holger Posts: 8116 Nutzer |
Zitat:Vielleicht hast Du zufällig ein paar mp3's, bei denen die Bitrate ein ganzzahliges Vielfaches der Framegröße ist. Oder Du berechnest eine falsche Länge und suchst danach nach dem nächsten sync, was zwar falsch ist, aber natürlich trotzdem hin und wieder funktionieren kann. Oder Du hast gerade das eine file vor Dir, bei dem es nicht funktioniert. Hergott, vier vbr-Dateien hast getestet, bei einer funktioniert das Programm nicht, und das bezeichnest Du als Funktionieren?! Willst Du ein Programm, daß die Funktion richtig ausführt, und zwar bei allen Dateien, oder willst Du ein Programm, daß zufällig bei ein paar Dateien, die Du gerade auf Deiner Platte hast, zu 90% funktioniert? Zitat:Was zur Hölle macht Dein Programm eigentlich? Wenn ein Xing-Tag vorhanden ist, handelt es sich um ein vbr-mpeg. Das kann durch Auswertung des Xing-Tags in quasi-Nullzeit analysiert werden. Bei Dateien ohne Xing-Tag weißt Du überhaupt nicht, ob es vbr-Dateien sind. Wie können diese "durchrasen"? Genau diese mußt Du doch analysieren, um herauszufinden, ob die Bitrate tatsächlich konstant ist. Wenn Du natürlich nur Dateien ohne konstante Bitrate scannst, bei denen es eigentlich überflüssig wäre, ist es natürlich auch kein Wunder, daß Deine fehlerhafte Behandlung des padding-bits keine Rolle spielt. Padding wird benutzt, um die Bitrate auf einen _konstanten_ Wert zu bringen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 09.08.2005 um 22:50 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 22:56 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich habe den Aufbau des Xing-Tags bereits auf der ersten Seite dieses Threads beschrieben, es gibt bereits funktionierenden Basic-Code dazu auf der Seite vier, was brauchst Du denn noch? Unter http://www.codeproject.com/audio/MPEGAudioInfo.asp wird's z.B. auch beschrieben. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2005, 22:59 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn wunderts bei seinen "Testmethoden". Wie Du selbst lesen kannst, hat er es nur mit vier Dateien getestet, mit 25% Fehlerquote, die er allerdings mit "nur eine Datei" umschreibt, klingt ja auch besser. Und reicht aus, um als "funktioniert bei mir" durchzugehen. Vielleich solltest Du Dir nicht zuviel Mühe bei dem Code machen...  mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 12:11 Uhr MaikG Posts: 5172 Nutzer |
>Ich hab auch mal versucht im Internet Infos über Xing >zu bekommen, also denn Aufbau, wurde aber nicht fündig. >Du scheinst da Dokus zu haben? Nein, ich weiss nur das die MP3 Datei wenn sie Xing enthält eine Variable bitrate hat. Einer hier hat auch gesagt das nach Xing die Frameanzahl kommt, jedoch finde ich da nichts sinnvolles. Kaputte mp3s gibts haufenweise bei Tauschbörsen, da kann der Xing kaputt sein, die Daten oder die Frames... >Vielleicht hast Du zufällig ein paar mp3's, bei denen die >Bitrate ein ganzzahliges Vielfaches der Framegröße ist. >Oder Du berechnest eine falsche Länge und suchst danach >nach dem nächsten sync, was zwar falsch ist, aber natürlich >trotzdem hin und wieder funktionieren kann. >Oder Du hast gerade das eine file vor Dir, bei dem es nicht >funktioniert. Also wenn ich padding abweichend berechne ist die laufzeit um 1 Minute verkehrt! >Hergott, vier vbr-Dateien hast getestet, bei einer >funktioniert das Programm nicht, und das bezeichnest >Du als Funktionieren?! Ich hab nunmal nicht mehr davon, ich hab kein DSL und bin daher keiner der sich ständig Musik zieht. Ich nenne das Funktionieren, du hast das Programm selbst gar nicht ausprobiert!. Nur Ralf und der hat gar keine Xing Dateien. Da der Teil des Programms für Xing bei ihm gar nicht durchlaufen wurde. >Willst Du ein Programm, daß die Funktion richtig ausführt, >und zwar bei allen Dateien, oder willst Du ein Programm, >daß zufällig bei ein paar Dateien, die Du gerade auf >Deiner Platte hast, zu 90% funktioniert? Das 1. ich kanns jedoch auch nicht ändern... Deins geht bei mir nicht. >Was zur Hölle macht Dein Programm eigentlich? Wenn ein >Xing-Tag vorhanden ist, handelt es sich um ein vbr-mpeg. >Das kann durch Auswertung des Xing-Tags in quasi-Nullzeit >analysiert werden. Machts auch. Dann liesst es ALLE Frames und berechnet die laufzeit. >Bei Dateien ohne Xing-Tag weißt Du überhaupt nicht, ob es >vbr-Dateien sind. Wie können diese "durchrasen"? Genau >diese mußt Du doch analysieren, um herauszufinden, ob die >Bitrate tatsächlich konstant ist. Nein, von den Ohne Xing habe ich etwa 100 getestet alle ohne VBR. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 15:23 Uhr Holger Posts: 8116 Nutzer |
Zitat:Meine Güte, dann lies doch nochmal nach! Nach den vier bytes kommen weiter vier bytes, die die Flags enthalten, und wenn deren unterstes Bit gesetzt ist, und nur dann folgen weiter vier bytes, die die Frameanzahl enthalten. Aber wenn ich mir Deine Programm so ansehe, pflegst Du ja stattdessen lieber den gesamten Dateiinhalt nach irgendetwas zu durchsuchen, was das gewünschte sein könnte, statt mal eine Dokumentation zu lesen. Zitat:Man kann auch selber mp3's produzieren. Ich habe mir übrigens jetzt mal Dein Programm angesehen, das Du hier gepostet hat. Dein Programm: Na ja, abgesehen davon, daß der Xing-Tag letztendlich sowieso nicht ausgewertet wird... Aber offenbar hast Du noch ein anderes Programm, "das meistens funktionmiert". Vielleicht postest Du das mal hier. Zitat:Und ich habe ca. 10000 Dateien gestestet, mit dem Ergebnis, daß vbr-Dateien ohne Xing Tag sehr wohl auftreten, auch wenn sie ziemlich selten sind. Man kann sich natürlich auch auf den Standpunkt stellen, daß man diese seltenen Fälle nicht berücksichtigen will. Aber in dem Fall brauchst Du Dein Programm überhaupt nicht zu optimieren. Behebe die grundsätzlichen Fehler in Deinem Programm, so daß Du den echten und auch wirklich ersten mpeg-frame analysierst, dann benutze entweder die Xing-Informationen oder gehe von CBR aus und nimmt die Bitrate des ersten Frames, und Du bist fertig. Und einige Deiner falschen Vorgehensweisen haben ja auch noch nagtiven Einfluß auf die Performance. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 15:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Kein Wunder, denn das padding-Bit hat überhaupt keinen Einfluß auf die Berechnung der Spielzeit. Wenn Du eine Formel benutzt, in der das padding eine Rolle spielt, kann nur Unsinn dabei herauskommen. Das padding brauchst Du ausschließlich zur Bestimmung der nächsten frame-Position. Wenn Du es richtig machst, findest Du einen frame, ansonsten nicht. Und wenn Du keine Abstürze produzieren willst, sollte Dein Programm sofort aufhören, wenn es keinen Anschlußframe findet, weil das ein Hinweis auf einen grundsätzlichen Fehler ist. Zumindest, solange Du keinerlei Plausibilitätschecks durchführst. Für die Berechnung der Spielzeit brauchst Du nur die Frequenz und die Anzahl der Frames, mehr nicht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 15:37 Uhr Holger Posts: 8116 Nutzer |
Zitat:Unter "Auswertung des Xing-Tags" verstehe ich das Auslesen der Frameanzahl aus dem Tag und sofortige Zurückliefern der Spielzeit, ohne sich die restlichen Frames anzusehen. Auswerten bedeutet mehr als nur die Anwesenheit von etwas zu bemerken. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 16:13 Uhr MaikG Posts: 5172 Nutzer |
>Meine Güte, dann lies doch nochmal nach! >Nach den vier bytes kommen weiter vier bytes, die die >Flags enthalten, und wenn deren unterstes Bit gesetzt ist, >und nur dann folgen weiter vier bytes, die die Frameanzahl >enthalten. Tut mir leid das ich nicht sofort alles verstehe was ich lese. >Man kann auch selber mp3's produzieren. BladeEnc macht nur normale mp3s ohne VBR. >o Durchsucht grundsätzlich die ersten 9215 bytes nach >dem ersten Mpeg-Header, warum auch immer und hört >danach auf. Muß zwangsläufig bei größeren >ID3v2-Headern versagen und dürfte bei kleineren >Dateien absturzfreudig reagieren, wenn es keinen >Mpeg-Header findet. Erst ab dem zweiten Frame wird >die tatsächliche Dateilaenge als Obergrenze benutzt Ich weiss ja nicht wie du Programme schreibst, bei mir gibt es Fehler und die werden auch irgendwann korregiert. Ich kenne keinen Progger der Fehlerfrei Programme scheibt. >o Nimmt die vollständige Dateigröße als >Berechnungsgrundlage, statt header und evtl. >nachfolgende Meta-Informationen von der Spieldauer >abzuziehen Richtig, ändert sich ggf. später mal, momentan hab ich nur eine mpeg Datei mit einem Jpeg Bild von ca.104 mpeg Dateien. >o Durchsucht völlig sinnlos die Datei nach einem >Xing-Header von der Mpeg-Frame Position bis zur absoluten >Position "9216" (warum auch immer), statt an der einzigen Ist noch nicht vorgekommen, das Xing woanders steht, aber wenn es eine Feste Position hat, kann ich das noch ändern. >o Daß das Programm falsche Mpeg2-Bitraten in der Tabelle >enthält Die Tabelle ist aus dem Internet und liefer bei 100/100 nicht VBR mpegs und 3/4 VBR Mpegs exakte werte. Der Rest ist schon lange Korregiert. >Aber offenbar hast Du noch ein anderes Programm, "das >meistens funktionmiert". Vielleicht postest Du das mal hier. Okay. >Kein Wunder, denn das padding-Bit hat überhaupt keinen >Einfluß auf die Berechnung der Spielzeit. Wenn Du eine >Formel benutzt, in der das padding eine Rolle spielt > kann nur Unsinn dabei herauskommen. Die Spiellänge wird jedoch aus der Framegröße berechnet, von daher muss ich mit dem padding bit rechnen. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 16:17 Uhr MaikG Posts: 5172 Nutzer |
DEFINT a-z REM REM $NOLINES REM $NOOVERFLOW REM $novarchecks REM $noarray REM $noautodim REM $noaddicon REM $NOSTACK '$INCLUDE exec.bh '$INCLUDE dos.bh LIBRARY OPEN "dos.library" LIBRARY OPEN "exec.library" REM *** wieso verwndest Du keine Datenfelder? Das Prog REM wird dadurch kürzer. Außerdem hatte ich den Hinweis vom REM Holger das die Daten nicht ganz korrekt wären, aber ich REM lass das hier mal so wie es ist. Bei Dir läuft es ja so DIM tbl%(14,6) tbl%(1,1)=32:tbl%(1,2)=32:tbl%(1,3)=32:tbl%(1,4)=32:tbl%(1,5)=32:tbl%( 1,6)=8 tbl%(2,1)=64:tbl%(2,2)=48:tbl%(2,3)=40:tbl%(2,4)=64:tbl%(2,5)=48:tbl%( 2,6)=16 tbl%(3,1)=96:tbl%(3,2)=56:tbl%(3,3)=48:tbl%(3,4)=96:tbl%(3,5)=56:tbl%( 3,6)=24 tbl%(4,1)=128:tbl%(4,2)=64:tbl%(4,3)=56:tbl%(4,4)=128:tbl%(4,5)=64:tbl %(4,6)=32 tbl%(5,1)=160:tbl%(5,2)=80:tbl%(5,3)=64:tbl%(5,4)=160:tbl%(5,5)=80:tbl %(5,6)=64 tbl%(6,1)=192:tbl%(6,2)=96:tbl%(6,3)=80:tbl%(6,4)=192:tbl%(6,5)=96:tbl %(6,6)=80 tbl%(7,1)=224:tbl%(7,2)=112:tbl%(7,3)=96:tbl%(7,4)=224:tbl%(7,5)=112:t bl%(7,6)=56 tbl%(8,1)=256:tbl%(8,2)=128:tbl%(8,3)=112:tbl%(8,4)=256:tbl%(8,5)=128: tbl%(8,6)=64 tbl%(9,1)=288:tbl%(9,2)=160:tbl%(9,3)=128:tbl%(9,4)=288:tbl%(9,5)=160: tbl%(9,6)=128 tbl%(10,1)=320:tbl%(10,2)=192:tbl%(10,3)=160:tbl%(10,4)=320:tbl%(10,5) =192:tbl%(10,6)=160 tbl%(11,1)=352:tbl%(11,2)=224:tbl%(11,3)=192:tbl%(11,4)=352:tbl%(11,5) =224:tbl%(11,6)=112 tbl%(12,1)=384:tbl%(12,2)=256:tbl%(12,3)=224:tbl%(12,4)=384:tbl%(12,5) =256:tbl%(12,6)=128 tbl%(13,1)=416:tbl%(13,2)=320:tbl%(13,3)=256:tbl%(13,4)=416:tbl%(13,5) =320:tbl%(13,6)=256 tbl%(14,1)=448:tbl%(14,2)=384:tbl%(14,3)=320:tbl%(14,4)=448:tbl%(14,5) =384:tbl%(14,6)=320 verz$="Work3:Janett/Mai2005/" rem mp3 Verzeichniss junk&=Execute&(SADD("c:list >T:MP3List.tmp sort=name FILES nohead quick "+verz$+"#?.mp3"+CHR$(0)), 0, 0) OPEN "T:MP3List.tmp" FOR INPUT AS #1 WHILE NOT EOF(1) INCR MP3Anz%:REDIM PRESERVE Files$(MP3Anz%):LINE INPUT #1,Files$(MP3Anz%) WEND FOR dat%=1 TO Mp3Anz% vbr%=0:alreadyfree%=0:bitraten&=0:frameanz&=0 filename$=verz$+Files$(dat%) Datei& = xOpen&(SADD(filename$ + CHR$(0)), MODE_OLDFILE&) IF Datei&=0 THEN END 'laenge ermitteln junk& = Seek& (Datei&,0,OFFSET_END&) dateilaenge& = Seek& (Datei&,0,OFFSET_BEGINNING&) inbuf& = AllocMem&(20000&,MEMF_PUBLIC&) IF inbuf& THEN rLen& = xRead&(Datei&,inbuf&,20000&) junk&=xClose&(Datei&) IF inbuf&=0 THEN END FOR i%=0 TO 9216 IF PEEKB(inbuf&+i%)=255 THEN a%=PEEKB(inbuf&+i%+1) IF a%>223 THEN Muster%=65280&+a% REM 1.2Bytes FF+xx REM ID%=(a% AND  8REM *** Die Zeile da oben liest nur REM ein Bit aus wie es in den orginal Frauenhofer Infos steht. Unten im Code REM wird auch nicht auf MPEG2.5 gerechnet, falls es kommen sollte. REM Fuer MPEG2.5 erkennung kommt folgendes dazu: ID%=(a% AND 24)8:REM 11 = MPEG 1, 00 10 = MPEG 2(.5), 01 invalid IF ID%=3 THEN ID%=1 ELSE ID%=0 Layer%=(a% AND 6)2 a%=PEEKB(inbuf&+i%+2) Bitrate%=(a% AND 240)16 Frequenz%=(a% AND 12)4 padding%=(a% AND 2)2 Musterz%=a% AND 15 First%=i% EXIT FOR END IF END IF NEXT IF id%=1 THEN REM MPG1 taby%=4-layer% IF Frequenz%=0 THEN Freq&=44100 ELSEIF Frequenz%=1 THEN Freq&=48000 ELSE Freq&=32000 REM 2=32000 END IF ELSE REM id%=0 MPG2 taby%=7-layer% REM 7-1=6 7-2=5 7-3=4 IF Frequenz%=0 THEN Freq&=22050 ELSEIF Frequenz%=1 THEN Freq&=24000 ELSE Freq&=16000 REM 2=16000 END IF END IF tabx%=bitrate% t!=TIMER FOR j%=i% TO 9216 a&=PEEKL(inbuf&+j%) IF a&=&h58696E67 THEN REM XING, Info ist doch nicht vbr FreeMem inbuf&, 20000&:alreadyfree%=-1 Datei& = xOpen&(SADD(filename$ + CHR$(0)), MODE_OLDFILE&) IF Datei&=0 THEN END inbuf&=AllocMem&(dateilaenge&,MEMF_PUBLIC&) IF inbuf& THEN rLen&=xRead&(Datei&,inbuf&,dateilaenge&) junk&=xClose&(Datei&) IF inbuf&=0 THEN END FOR i&=first% TO Dateilaenge&-1 REM IF PEEKB(inbuf&+i&)=255 AND PEEKB(inbuf&+i&+1)>223 THEN IF PEEKW(inbuf&+i&)=Muster% THEN REM 1s abweichung, jedoch deutlich schneller. a%=PEEKB(inbuf&+i&+2) REM IF (a% AND 12)4=Frequenz% AND (a% AND 2)2=padding% THEN REM kann auch noch Falscher Frame sein REM padding soll sich zwar ändern können, Funktioniert jedoch so ohne abweichung. IF (a% AND 15)=Musterz% THEN tabx%=(a% AND 240)16 IF tabx%<15 THEN REM Valied Bitrate ohne 0 da genauer bitrate%=tbl%(tabx%,taby%) Bitraten&=Bitraten&+bitrate% INCR frameanz& IF Layer%=1 THEN REM 384 Samples bei Layer1 frameLength&=(12*Bitrate%(Freq&/1000)+Padding%)*4 ELSE IF Layer%=2 OR ID%=0 THEN REM 1152 Samples Layer2 oder L3+MPEG1 frameLength&=144*Bitrate%(Freq&/1000)+Padding% ELSE REM 576 Samples Layer3, MPEG 2 oder MPEG2.5 frameLength&=72*Bitrate%(Freq&/1000)+Padding% END IF END IF IF frameLength& THEN i&=i&+frameLength& END IF END IF END IF NEXT PRINT "Dauer:",TIMER-t!; PRINT "VariableBitRate":vbr%=1:EXIT FOR END IF NEXT IF alreadyfree%=0 THEN FreeMem inbuf&, 20000& IF vbr% THEN REM PRINT "Anzahl",frameanz&,"Bitraten",bitraten& tmp&=((bitraten&*1000)/frameanz&) tmp&=(144*tmp&/Freq&)+(padding%*frameanz&) sec%=(Dateilaenge&/tmp&)/38.5 FreeMem inbuf&, dateilaenge& END IF IF tabx%=15 THEN PRINT "fehler" REM *** Hat ich hier in meiner MP3-Sammlung zuhauf. Hab ich eingebaut damit REM ich es mal durchlaufen lassen konnte. ELSE bitrate&=tbl%(tabx%,taby%) bitrate&=bitrate&*1000 END IF Framesize%=FIX((144*Bitrate&/Freq&)+padding%) IF vbr%=0 THEN sec%=(Dateilaenge&/Framesize%)/38.5 MINU%=sec%60 sec%=sec%-minu%*60 PRINT Files$(dat%)+" "+RIGHT$("00"+LTRIM$(STR$(MINU%)),2)+":"+RIGHT$("00"+LTRIM$(STR $(sec%)),2) NEXT dat% [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 18:11 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist nicht der Punkt. Du versuchst es nicht einmal und tust so, als wären diese Informationen nie gepostet worden. Statt Dich mit der Information, wie es richtig funktioniert, auseinanderzusetzen, probierst Du solange rum, bis es zufällig mal funktioniert. Zitat:Man kann Fehler machen, aber das ist es hier nicht. Da solltest Dich endlich mal mit der grundsätzlichen Herangehensweise beim Programmieren beschäftigen. Wenn Du keine Ahnung hast, was das Programm überhaupt machen muß, um zu einer richtigen Lösung zu gelangen, solltest Du gar nicht anfangen, source-code zu schreiben. Stattdessen muß man die notwendigen Informationen sammeln und sich Gedanken darüber machen, wie das Programm prinzipiell funktionieren muß. Dann kann man anfangen, source-code zu produzieren. Also nicht: "ich durchsuche einfach mal einen durch Ausprobieren gewählten Bereich von 9216 bytes" Sondern: ich informiere mich darüber, unter welchen Bedingungen ich wo einen Header finden kann, und an welchen Stellen keiner sein kann. Zitat:Es hat keine feste Position. Es hat steht nach dem MPEG-Header, dessen Größe von den Eigenschaften des Mpegs abhängt, wie Version und Kanalmodus. Du hast wahrscheinlich noch nie ein Mono-Mpeg getestet, stimmts? Bist noch nie auf die Idee gekommen, daß es Mono-Mpegs überhaupt gibt, was? Nochmal: Man programmiert nicht durch ausprobieren Damit kommen Programme wie Deins heraus, daß bei Dir funktioniert und gleich beim nächsten, in diesem Falle Ralf, abstürzen. Zitat:Mensch, versuch es doch mal mit Nachdenken und mit einer logischen, systematischen Vorgehensweise. Deine Programm enthält falsche Daten für Mpeg2, also mußt Du es auch mit Mpeg2- Dateien testen. Davon lese ich in Deiner Antwort nichts. Wieder nur Dein standard "mit meinen 100 Dateien funktionierts". Laß mich wieder raten: Unter Deinen hundert Dateien befindet sich natürlich auch keine Mpeg2-Datei? Zitat:Blödsinn. Nochmal: die Spiellänge hängt ausschließlich von der Anzahl der Frames und der Frequenz ab. Logisch, denn das padding bit ist, wie der Name sagt, nur ein Füll-Bit, es enthält keine Audio-Daten. Ein frame mit padding hat exakt dieselbe Spielzeit wie eines ohne. Ich kanns nur nochmal betonen: logisch vorgehen, die nötigen Informationen zusammentragen und den Algorithmus für das richtige Verfahren entwickeln. Nicht herumprobieren und wenns zufällig mit irgendeinem Beispiel funktioniert, behaupten, daß es jetzt läuft, obwohl Du gar nicht genau weißt, was das Programm jetzt eigentlich wirklich macht. mfg PS: Wenn Du eine Software kaufst und diese bei Dir abstürzt, bist Du doch auch sauer, wenn der Hersteller sagt, "also auf meinem Rechner funktionierts, also funktioniert es. Wenn Du eine andere Konfiguration als ich benutzt, bist Du selbst Schuld." -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 10.08.2005 um 18:16 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 18:59 Uhr MaikG Posts: 5172 Nutzer |
>Das ist nicht der Punkt. Du versuchst es nicht einmal >und tust so, als wären diese Informationen nie gepostet >worden. Die allgemeine Information über Xing habe ich nicht verstanden. Ich habe nie behauptet das ich Profi bin, du tust aber so. >Wenn Du keine Ahnung hast, was das Programm überhaup >machen muß, um zu einer richtigen Lösung zu gelangen, >solltest Du gar nicht anfangen, source-code zu schreiben. Ich hab mich informiert, dann geschrieben. Dann hab ich festgestellt das es auch mp3s mit Variabler bitrate gibt. Dann habe ich mich darüber Informiert und im Internet gelesen das man um da die Laufzeit zu ermitteln muss man die ganze mp3 datei durchsuchen muss. Das macht mein Programm, für mich auch ganz gut jedoch nicht schnell. >Also nicht: "ich durchsuche einfach mal einen durch >Ausprobieren gewählten Bereich von 9216 bytes" Ich hab schonmal gesagt, für mich funktionieren diese 9216 bytes. Solche kleinen korrekturen kommen später. Erstmal muss das Programm ausreichend schnell sein. >Nochmal: Man programmiert nicht durch ausprobieren Damit >kommen Programme wie Deins heraus, daß bei Dir >funktioniert und gleich beim nächsten, >in diesem Falle Ralf, abstürzen. Bei Ralf ist es nicht abgestürzt sondern ergab eine Fehlermeldung. Und ich kann das genauso zu dir sagen, da dein programm bei mir auch Fehlermeldungen ausgibt. Ansonsten kann ich dich beruhigen ich entwickle ja nicht OS4, du musst mein Programm nicht benutzen, sofern das überhaupt mal veröffentlicht wird. >Mensch, versuch es doch mal mit Nachdenken und mit einer >logischen, systematischen Vorgehensweise. Deine Programm >enthält falsche Daten für Mpeg2, also mußt Du es auch mit >Mpeg2- Dateien testen. Mit etwas was ich nicht habe kann ich nicht testen. >Blödsinn. Nochmal: die Spiellänge hängt ausschließlich >von der Anzahl der Frames und der Frequenz ab. Logisch, >denn das padding bit ist, wie der Name sagt, nur ein >Füll-Bit, es enthält keine Audio-Daten. Ein frame mit >padding hat exakt dieselbe Spielzeit wie eines ohne. Laut Internet Framesize=(144*Bitrate/Samplerate)+padding und Seconds=(Dateisize/Framesize)/38.5 Das hab ich nicht erfunden, das hat auf anhieb für normale mp3s Funktioniert. Für welche mit VBR in abgewandelter Form auch. Vielleicht könntest du mir bitte das mit den VBR Berechnen mal für dumme erklären, anstatt mich immer nur zu kretisieren. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 20:09 Uhr Holger Posts: 8116 Nutzer |
Zitat:Du bist noch nicht einmal ein Anfänger. Was ist daran nicht zu verstehen: 12 bytes vier bytes 'X' 'i' 'n' 'g', gefolgt von vier bytes a b c d, die die flags ergeben, wenn das unterste bit von d gesetzt ist, gilt: vier bytes e f g h, die zusammmen eine vier byte integer Zahl ergeben -> die Anzahl der Frames Herrje, Du hast in Deinem eigenem Programm mit PEEKL herumhantiert, also muß Du das doch verstehen. Oder sag uns einfach, wer das ursprüngliche Programm geschrieben hat, dann reden wir mit ihm. Zitat:Hast Du nicht denn Zitat:Es gibt offenbar immer noch keine logische Begründung, warum Du das gemacht hast. Das beweist, daß Du nicht vorher nachgedacht hast. Zitat:Falsch, grundsätzlich falsch!! Erstmal muß ein Programm funktionieren, nicht abstürzen und die korrekten Werte liefern, bevor man auch nur einen Gedanken an die Geschwindigkeit verschwendet. Dein Programm funktioniert nicht mal ansatzweise richtig, und liefert nur per Zufall in bestimmten Situationen richtige Werte. Zitat: Und damit kommen wir zu dem Punkt, wo sich jede weitere Diskussion erübrigt. Scrollen wir nach oben, egibt sich folgender Dialog. MaikG: Mein Programm funktioniert Holger: Dein Programm enthält fehlerhafte Daten für Mpeg2 MaikG: Mein Programm funktioniert!! Holger: Du mußt Du es auch mit Mpeg2- Dateien testen. MaikG: Mit etwas was ich nicht habe kann ich nicht testen. Zitat: So, jetzt versuchen wir es mal wie richtige Programmierer, ja? Also mit logischem Nachdenken. Dazu vergessen wir einfach mal alles was wir je im Internet gelesen haben. Wir vergessen sogal mal, daß so etwas wie MPEG überhaupt existiert Oooommmmmmmm vergessen... Oooommmmmmmm ... Also: was ist ein Sample? Ein Wert eines Audiodatenstroms, ein Zahl, bei Stereo zwei Zahlen. was ist eine Frequenz? In unserem Falle die Anzahl Samples pro Sekunde Wenn jemand auf die Idee käme, ein Musikstück in kleine Blöcke, nennen wir sie mal frames von fester Anzahl Samples zu zerteilen. Was erhält man, wenn man die Anzahl frames eines Musikstücks mit dieser festen Anzahl Samples pro frame multipliziert? samples/frame * frame == samples Man erhält die Gesamtanzahl Samples. Was passiert, wenn man diese Gesamtanzahl samples durch die Frequenz, also der Anzahl Samples pro Sekunde teilt? samples / ( samples / sekunde) = (samples / samples) * sekunde =sekunde Man erhält die Anzahl der Sekunden. Wie man sieht, ist diese Formel mit Grundwissen der 5. Klasse lösbar, wenn man dem Schüler nur sagt, was ein sample und was ein frame ist. Und was ein sample und ein frame ist, sollte jemand, der programmieren will und sich über die Thematik ausreichend informiert hat, bekannt sein, oder? Wenn also die Formel Anzahl Sekunden = Anzahl Samples pro Frame * Anzahl Frames / Frequenz so total einfach und logisch ist, daß wirklich nichts sie in Frage Stellen kann, weil sie sich aus den Begriffen selbst definiert, was bringt dann jemanden dazu, eine andere, viel kompliziertere Formel zu verwenden? Offenbar die Tatsache, daß er nicht zugeben will, daß, wenn die resultierende Zeit nicht stimmt, bereits die Eingangswerte falsch sind. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ Dieser Beitrag wurde von Holger am 10.08.2005 um 20:45 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 20:27 Uhr Holger Posts: 8116 Nutzer |
Ich hab mir den neuen source-code angesehen. Abgesehen davon, daß alle genannten Fehler immer noch enthalten sind (wie war dasZitat:? ) gibt es natürlich noch eine ganze Menge mehr. Es fällt sofort auf, daß der scan munter weiter in der Schleife läuft, auch dann, wenn er die frame-Länge nicht richtig berechnet hat¹, und so Gott will, hin und wieder sogar mal in einem der späteren Schleifendurchläufe vielleicht wieder auf einem frame landet. Da ist es schon ganz praktisch, daß das Programm die gefundenen Bitraten aufsummiert und durch die Anzahl der gefundenen frames teilt. Damit kommt natürlich irgendeine durchschnittliche Bitrate in realistischem Rahmen heraus und je nachdem, wieviel Prozent der frames denn nun tatsächlich gefunden wurden, könnte sie sogar ungefähr stimmen. Der erste Schritt für richtiges Programmieren wäre es, sofort abzubrechen, sobald kein oder ein ungültiger frame-header gefunden wurde. Dann merkt man nämlich, wenn das Programm Fehler enthält. Dann wird in einer unnötig komplizierten, dreizeiligen Berechnung alles eliminiert, was man an Informationen gewonnen hat, so daß am Schluß doch nur eine grobe Daumenpeilung herauskommt, die dann wieder stimmen kann. Bei dieser spielt die falsche Frameanzahl keine Rolle mehr, so daß natürlich die einfachere, korrekte Berechnungsmethode, bei der nur die Frameanzahl eine Rolle spielt scheinbar falsch ist, Weil schon die Anzahl der Frames falsch ist. Daß die einfachere Rechnung aber grundsätzlich richtig ist, konntest Du hoffentlich jetzt endlich nachvollziehen. Ich empfehle, einfach mal mehrere Lösungswege zu implementieren, so daß das Programm sie vergleichen und sich quasi selbst testen kann. Wenn es dann irgendwann mal mit mehr als nur Deinen hundert Dateien funktioniert, kannst Du sie ja immer noch entfernen. Daß außerdem noch eine frame-Längenkonstante, die nur bei Mpeg1-Layer3 oder Mpeg2-Layer2 Gültigkeit hat, verwendet wird (in der Schleife dagegen werden alle Fälle berücksichtigt), steht dann noch auf einem ganz anderem Blatt. Das mit der frame-Länge, die nur für bestimmte Dateien richtig ist, gilt natürlich auch für die Berechnung bei konstanten Bitraten, wobei immer noch die Dateilänge ohne Abzug von Headern und nachfolgenden Tags benutzt wird. Aber das hatten wir ja schon ganz oben... Fazit: das Programm strotzt so vor Fehlern, daß es gar kein Wunder ist, daß, wenn man einen einzelnen korrigiert, die Fälle, bei denen es bisher durch Zufall funktioniert hat, nicht mehr funktionieren. mfg ¹ und das dort ein grundsätzlicher Fehler enthalten ist, sehe ich auf den ersten Blick. Sobald da eine Bereitschaft zu erkennen ist, sich wirklich mal ernsthaft damit auseinanderzusetzten, anstatt immer zu behaupten, es würde funktionieren, sage ich auch, woran man erkennt, daß der Code auf diese Weise gar nicht funktionieren kann. Der erste Schritt auf dem Weg zur Fehlerbehebung, ist sie zuzugeben. Du bist nicht Microsoft, Du kommst mit dem Abstreiten nicht ein bißchen weiter. [ Dieser Beitrag wurde von Holger am 10.08.2005 um 20:31 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 21:33 Uhr Ralf27 Posts: 2779 Nutzer |
Hallo ihr beiden. Hm, schade das hier gerade etwas dicke Luft ist, aber ich kann de Holger verstehn. Maik, mach dich locker, de Holger möchte dir/uns ja helfen. Jedenfalls hab ich durch diesen Thread hier sehr viel über MPEGs, Frames und denn Aufwand der Laufzeitberechnung gelernt. Wegen Xing: Ich wollte eigentlich dazu nur noch wissen was da alles vorhanden ist im Xing-Tag. Wenn da halt nur AnzahlSampes und Dateilänge vorhanden ist und das alles ist, dann ist es ja ok. Ich dachte halt, das es da noch mehr gibt in diesem Tag. Wegen ID3xx: Es ist schon eine interesante Sache, die ID3v1-hab ich jetzt interessenhalber eingebaut und ID3v2 und höher ist wirklich sehr aufwändig und ich wußte bis zu diesem Thread nicht das man sogar ein Bild in eine MPEG-Audiodatei einbauen kann. Achja, MaikG, wegen deinem Programm: Also bei mir läd der Rechner eine MPEG-Audiodatei (ca. 4MB) in ca. einer Sekunde. Ich denk mir mal das du auch einen 060er-Rechner hast(vermutung), also kann es auch nicht so lange dauern. Dein Programm wirft hier bei mir wirklich sehr viele Fehler (z.b. Bitrate=15=illegaler Wert). Wenn man halt nicht genügend Testedateien hat, dann ist es halt etwas bescheiden. Ich hab hier wirklich einige Dateien zum testen. Achja, es gibt aber auch da einige Dateien, da werden leider auch keine Header gefunden, auch nicht mit meinem/Holger seinem Programm. Und es gibt auch ein Problem mit einer Xing-Datei die ich hier habe, das ich plötzlich unglaubliche viele Frames habe, was nicht sein kann. Ich werd mich später nochmal damit beschäftigen, muß aber kurz noch was Haushalttechnisches machen. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 21:57 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ein bißchen mehr. Folgende Flags sind definiert 0x0001 - Frames verhanden 0x0002 - Anzahl bytes vorhanden 0x0004 - Inhaltsverzeichnis? vorhanden 0x0008 - Qualitätsinformation vorhanden Zu beachten ist: wenn ein flag nicht gesetzt ist, ist der Eintrag nicht nur ungültig, er fehlt komplett, die nachfolgenden beginnen dementsprechend eher. Wenn frames vorhanden sind, folgt eine vier byte Zahl , wenn Byteanzahl vorhanden, folgt noch eine.Dannnn folgen hundert bytes "Inhaltsverzeichnis", wenn das entspr. flag gesetzt ist, über das ich auch nicht mehr weiß, gefolgt von einer vier byte Zahl, wenn das Qualitätsinformations-Flag gesetzt ist. Letztere enthält eine Zahl von 0..100, kleinere Zahlen bedeuten bessere Qualität. Um das Maß voll zu machen, könnten dann noch die vier bytes 'L' 'A' 'M' 'E' folgen, die besagen, daß eine LAME-Extension folgt. Aber das geht mit jetzt wirklich zu weit  Zitat:Ja, ich habe mehrere solcher Dateien. Nur kein Programm, daß sie mir anzeigt. Ich schreibe zwar an einem, deshalb der ID3lib-Port, aber das ist ein Laaaaaangzeitprojekt. Ich habe auch mind. eins, bei dem die Daten nicht maskiert wurde. D.h. wenn ein Programm den ID3-Tag nicht überspringt, und den Sync-Check nicht penibel genug macht, hält es den JPEG-Header für einen Mpeg-Header. Interessanterweise scheinen die meisten Programm damit klar zu kommen. Nur als Info, welche Dinge mir beim Test des Programms so über den Weg gelaufen sind... Zitat:Wie schon gesagt, die frames werden nicht korrekt übersprungen. Wenn Du an falscher Stelle nach einem sync suchst, können sehr schnell zufällige bytes wie ein mpeg-header aussehen, der aber ungültige Daten enthält. Den Header mit dem des ersten gefundenen Frames zu vergleichen, war übrigens eine gute Idee, das dürfte den Fehler reduzieren. Allerdings auch die eigentlichen Probleme verschleiern. Zitat:Dafür kann es eine ganze Reihe von Ursachen geben. Ich habe schon einige gefunden. Aber langsam beginnt Basic mich wirklich zu nerven. Insbesondere, wenn die Möglichkeiten, die Struktur wirklich zu verbessern, vom Basic Dialekt abhängen. Und MaxonBasic nicht will... Zitat:Wie ich schon sagte.... Hast Du auch mal versucht, die Dateien, die Probleme machen, zu kategorisieren? Mpeg-Version, Layer, Xing vorh., ID3-Tag vorh., andere Headerdaten etc.? Das/Die Muster dahinter wäre ziemlich interessant. Einige habe ich, wie schon vorige Woche gesagt, identifiziert. Bleibt die Frage, ob Du die gleichen findest. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 22:06 Uhr Holger Posts: 8116 Nutzer |
@Ralf27: Andere Sache. Kann man die .bh files irgendwie generieren oder von irgendwoher beziehen? Vielleicht löst sich das MaxonBasic Problem auf diese Weise.... mfg Nachtag: hab das Problem gefunden. Hat sich somit erledigt. Und so eine Ahnung, wie ich mir bh files basteln kann, auch. Wollen ma schauen, ob man damit möglicherweise sogar das 256 Zeilen Limit umgehen kann. [ Dieser Beitrag wurde von Holger am 10.08.2005 um 23:23 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 23:40 Uhr MaikG Posts: 5172 Nutzer |
Jetzt hab ich es kappiert, eigentlich ist es ganz einfach. Aber ich hab das geglaubt was ich zuerst im Internet gefunden habe. Mein Programm liesst jetzt schonmal alle Xings aus und berechnet daraus die Spiellänge(4/4 Xing mp3). Fehlerhafte Frames im 1.Teil des Programms werden jetzt abgefangen. Fehlt noch "VBRI" - was nicht lange dauert, dann noch dieses Tag zeugs abzurechnen und die Tabelle zu überprüfen. Die Geschwindigkeit der Berechnung ist jetzt nicht mehr erfassbar :-) [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 23:51 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Also, ich könnte dir die bh-Files senden. Das wird wohl genau so sein wie mit den bmaps-Files. Die bhs kann man ja auch selbst generieren, allerdings kann man da bhs auch falsch versteh.   MBasic hat als noch für mich einige Überraschungen und das obwohl das Prog von 1994(!) ist. Da sieht man mal wie weit ich Programmiertechnisch hintendran bin... -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2005, 23:55 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Dann dürftest du jetzt wohl auch bei ca. 0.1-0.2Sekunden Durchsuchungszeit kommen, wenn man mal das Laden vorher nicht beachtet. Aber gerade das mit den Dokus im Internet ist so eine Sache. Was hab ich da schon alles an Daten gefunden, die aber *falsch* sind. Da kann man halt lange rumtesten und sich wundern das nix geht. Und mir ist aufgefallen das gerade englische Doku irgendwie professioneller ist als die Deutsche. Keine Ahnung wieso. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 00:12 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat:Wos, LAME macht da auch TAGs rein? Da will sich wohl jeder MP3-Packer irgendwie verewigen. Ich hab eigentlich alle selbstgepackten MP3s mit Lame gepackt. Da werd ich später auch mal im Internet nachsehn was da es alles dazu gibt.Zitat:Die Idee hatte ich vor kurzem auch schon, weil ich auch kein Prog für den Amiga kenne der das macht. Das fehlt irgendwie noch auf unserer Freundin. Aber ich glaub kaum das ich das schaffen könnte wenn ich selbst schon bei der Laufzeitberechnung so strauchel. Aber dennoch versuch ich es einfach mal. Mehr als nicht funktionieren kann ja nicht passieren. Zitat:Das werde ich bald noch machen, aber ich muß auch wieder in die Falle. Heute geht es wieder früh los. Zitat:Das werden wir dann heute ( ) Abend sehn, dann teste ich mal mein ganzes Archiv durch seh mal was da alles passiert.-- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 09:36 Uhr Solar Posts: 3680 Nutzer |
Bitte weitermachen, das ist lustig.  @ Maik: An einer Stelle muß ich Holgers Aussage noch einmal verstärken: Ein schnelles Programm, das nicht zuverlässig präzis korrekte Ergebnisse liefert, ist nur in den allerseltensten Fällen sinnvoll. Ein präzis korrektes Programm, das ineffizient arbeitet, ist in den allermeisten Fällen sinnvoll. Zur Steigerung der Effizienz gibt es sehr mächtige Entwicklerwerkzeuge (Profiler). Hat man aber erst einmal die Korrektheit großflächig vermurkst, macht das Arbeiten an den Sourcen überhaupt keinen Spaß mehr - denn das ist übelste Handarbeit. Erst die richtigen Ergebnisse. Dann optimieren. Schon beim Erstellen der richtigen Ergebnisse halbwegs optimalen Code zu produzieren ist was für Fortgeschrittene. Oder, um Donald Knuth zu zitieren: "Premature optimization is the root of all evil." [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 10:42 Uhr MaikG Posts: 5172 Nutzer |
>Dann dürftest du jetzt wohl auch bei ca. 0.1-0.2Sekunden >Durchsuchungszeit kommen, wenn man mal das Laden vorher >nicht beachtet. t!-timer vor For und nach verlassen der Schleife liefert entweder 0 oder eine 7E irgendwas. Die berechnung ist derart einfach das diese kaum Zeit benötig. [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 12:03 Uhr Ralf27 Posts: 2779 Nutzer |
Zitat: Ja, wenn bei dir ein Xing kommt, dann geht das in quasi 0 Sekunden. In 0.1-0.2 ist die ganze Datei durchsucht, wenn keine Xing vorhanden ist. Den Lame-Tag versuch ich später mal im Internet zu finden. Mal sehn was da drin steht. Denn die meisten MP3 sind bei mir mit LAME gepackt. Jetzt mach ich aber erst mal ne gediegene Mittagspause. -- http://www.alternativercomputerclub.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 13:05 Uhr gni Posts: 1106 Nutzer |
Zitat:Schau Dir die Quellen der libmad an. Da wird sowohl der Xing- als auch der Lame-Tag ausgewertet. [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2005, 13:53 Uhr MaikG Posts: 5172 Nutzer |
>Den Lame-Tag versuch ich später mal im Internet zu finden. >Mal sehn was da drin steht. Denn die meisten MP3 sind >bei mir mit LAME gepackt. Ich hab 3 VBR-Lame(3.90/3.93 Dateien, die enthalten Xing. Daher für die Laufzeitberechnung scheints bei denen nicht relevant. [ - Antworten - Zitieren - Direktlink - ] |
| Erste 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. |
|