|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > BETA Version der blademp3.library fertig - bitte testen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
13.07.2006, 15:33 Uhr Micha1701 Posts: 938 Nutzer |
Hallo zusammen! Nach diversen Hürden und neuen Erkenntnissen freue ich mich endlich die BETA Version der blademp3.library zu bekunden. Wäre nett, wenn sich ein paar Interessierte bei mir melden würden um das ganze mal zu testen. Hab ein kleines Programm geschrieben, welches die Lib öffnet ein WAV in ein MP3 umwandelt und diese MP3 mit einem vorher umgewandelten Referenz-MP3 vergleicht. Geschwindigkeit und Fortschritt werden von dem Beispielprogramm angezeigt. Ein erster Test auf OS4 war übrigends katastrophal, weshalb diese Version erstmal nur auf 68K oder MOS getestet werden soll. MOS hab ich selber nicht, aber vielleicht fluppts da ja... An die OS4 Kompatibilität bzw. eine entsprechende native Version mach ich mich dann sobald die 68k Version einwandfrei läuft. Hab das übrigends hier veröffentlicht, weil es ja ne Library ist und kein eigenständiges Programm - also eher was für die Programmierer unter uns... --  Micha http://www.Silicon-Wizards.com [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2006, 15:45 Uhr bubblebobble Posts: 707 Nutzer |
Interessant, wäre was für HD-Rec. Ist Blade auf LAME basierend ? -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2006, 16:50 Uhr Micha1701 Posts: 938 Nutzer |
@bubblebobble: Nein, Blade basiert auf Blade :-) Den ursprünglichen Blade MP3 Encoder hat Tord Jansson geschrieben. Den Source bekommt man z.B. auf seiner Seite http://bladeenc.mp3.no/ zum runterladen. Ich hab den Source auf den 68k Amiga angepasst und eine Library erstellt. Sowas wird langsam mal Zeit. LAME war meine erste wahl, aber der Source war mir noch etwas zu unübersichtlich. Blade war da einfacher gestrickt. Werd mich später mal an LAME ranmachen. Der ist wohl um ein paar takte besser und schneller. Das Problem bei Blade ist, daß er Teile der mp3 ISO Referenz verwendet. Daher gibts da wohl probleme mit Patenten. Blick ich aber nicht so recht durch. Außerdem wird Blade seit Jahren nicht weiterentwickelt... -- Micha http://www.Silicon-Wizards.com [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2006, 18:07 Uhr gni Posts: 1106 Nutzer |
Zitat:Zusammen mit den Quellen würde ich es testen wollen (AOS/MOS). [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2006, 18:08 Uhr MaikG Posts: 5172 Nutzer |
Schickst du es mir? Muss eh noch ein paar MP3's encoden, Lame ist darin aber sehr langsam... MaikG492 at freenet punkt de [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 06:55 Uhr Micha1701 Posts: 938 Nutzer |
@MaikG: Tja, da muß ich Dich enttäuschen. Blade ist doch ein gutes Stück langsamer als LAME. Hab das grad mal getestet und LAME braucht für mein test.wav nur 1 Sekunde, während BLADE 16 braucht (auf nem WinUAE). Der einzige vorteil der BLADE.library ist eben, daß man sie einbinden kann... Sollte mich dann wohl doch mal an eine LAME.library machen. Aber dazu komm ich später... -- Micha http://www.Silicon-Wizards.com [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 07:47 Uhr MaikG Posts: 5172 Nutzer |
>Tja, da muß ich Dich enttäuschen. Blade ist doch ein gutes Stück >langsamer als LAME. Blade macht schneller als echtzeit auf einen 603e, Lame braucht in der aktuellen Version(viel ältere Version 30M) fast eine Stunde für ein mp3 auf 68060. >Hab das grad mal getestet und LAME braucht für mein test.wav nur >1 Sekunde, während BLADE 16 braucht (auf nem WinUAE). Der einzige >vorteil der BLADE.library ist eben, daß man sie einbinden kann... WinUAE kannst du nicht als Testbasis nehmen, da stimmt kein Geschwindigkeitstest und das ist von etlichen faktoren abhängig. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 11:08 Uhr bubblebobble Posts: 707 Nutzer |
@MaikG WinUAE kann man schon zum benchen nehmen, warum nicht ? Evtl schwankt die CPU Leistung wenn Windows was im hintergrund macht, aber das sind vielleicht +- 10%. Hier reden wir aber über Echtzeit vs. 1 Stunde pro Song, oder 1s vs 16s. Ich denke dass LAME schon recht schnell und auch qualitativ gut ist. Da steckt auch wesentlich mehr Entwicklung drin. @Micha1701 Wenn du vorhast auch LAME als lib zu implementieren, dann mach doch eine "über-Lib", z.B. mp3encode.library, bei der man dann den Encoder auswählen kann. Dann muss ein Application Progger nicht jede Lib einzeln einbauen. Allerdings denke ich, das mit einer LAME.libary die blademp3.library eher uninteressant ist. Falls du code zu OS4 libraries brauchst, kann ich dir das schicken. Ich habe ja die DSP Effekte von HD-Rec als library für OS4, MOS, 68k und x86 Amtihlon. (dank der Arbeit von Thomas und Pasi, soll nicht unerwähnt bleiben). Amithlon läuft allerdings noch nicht richtig. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 11:34 Uhr MaikG Posts: 5172 Nutzer |
>WinUAE kann man schon zum benchen nehmen, warum nicht ? Weil eine Instruktion schneller als eine andere Instruktion ausgeführt wird. Und wenn Programm a nun zufällig die schnellen benutzt und programm b zufällig die langsamen... Auf 68k werden diese gleich schnell ausgeführt. Sysspeed etc. geben da auch fantasiewerte aus. Oder nimm dnetc_68k, zeigt beim Benchmark 3 fache 68060 Geschwindigkeit an, mein Amiga hat den komischerweise überholt(auch 68k Version). [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 11:50 Uhr Holger Posts: 8116 Nutzer |
Zitat: Dass 68k-Instruktionen alle gleich schnell ausgeführt werden, kannste knicken. Das unterscheidet sich auch von Version zu Version, nicht umsonst haben optimierende Compiler eine target-Auswahl. Und wenn Programm a auf Deinem System zufällig die schnellen Instruktionen benutzt und Programm b zufällig die langsamen, dann kann es Dir egal sein, ob das auf einem anderen System umgekehrt ist. Deshalb sind Benchmarks auch immer mit Vorsicht zu genießen, insb. wenn die Rahmenbedingungen nicht genannt werden. Bei Faktor 10-100 kann man allerdings schon allgemeine Annahmen daraus ableiten. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 11:57 Uhr Holger Posts: 8116 Nutzer |
Zitat: Äpfel und Birnen? Oder, genaugenommen, Äpfel und ähm Kleiderständer? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 12:20 Uhr bubblebobble Posts: 707 Nutzer |
Ich denke SysSpeed bringt aus mehreren Gründen fantasie Werte. Einmal, weil kein realer Code läuft sondern (denke ich mal) ein enger Benchmark code, der möglicherweise vom JIT wegoptimiert wird, da Ergebnisse von Operationen wieder verworfen werden. Zum zweiten, ist vermutlich die Benchmark Dauer nicht lang genug, und damit die Genauigkeit nicht hoch genug. Als Sysspeed geschrieben wurde, war man eben noch nicht auf 1GHz+ Rechner vorbereitet. Das alles hast du aber nicht, wenn du mit einer Stopuhr das mp3 encoden misst, weil hier kein Ergebnis wegoptimiert werden kann, es st realer code, und die Zeitdauer ist auch real, und nicht aus 1ms hochextrapoliert. Was ich damit sagen will: Wenn LAME 2min für einen Song braucht, und Blade 10min, dann ist LAME eben schneller. Zumindest auf der Emu, aber alles was über dem faktor 2 liegt ist auch ziemlich sicher auf allen anderen Systemen schneller, bzw. es lässt sich einfach eine Tendenz ablesen. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
14.07.2006, 18:14 Uhr MaikG Posts: 5172 Nutzer |
>Dass 68k-Instruktionen alle gleich schnell ausgeführt werden, >kannste knicken. >Das unterscheidet sich auch von Version zu Version, nicht umsonst >haben optimierende Compiler eine target-Auswahl. Ist das nicht deswegen weil z.B. den 040er einige 030er Instruktionen fehlen? >Äpfel und Birnen? >Oder, genaugenommen, Äpfel und ähm Kleiderständer? Lame ist von Version zu Version langsamer geworden, daher meine annahme das der Code geschwindigkeitsmäßig nichts taugt. Das ein 603e kein 68k ist ist klar. Aber das der 68060 17 mal (60/3,5) langsamer als der 603e ist stimmt nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
15.07.2006, 11:39 Uhr bubblebobble Posts: 707 Nutzer |
Die neueste Version von LAME ist deutlich schneller geworden bei den Standard Einstellungen als die vorherigen. Hängt aber alles auch immer vom Compiler an, und ob man single oder double float nimmt. Bei LAME gibt es da wohl die option das beim compilieren auszuwählen. Wie auch immer, ich würde jede wette eingehen, das LAME bei vergleichbarer Qualität der schnellste mp3 decoder für den Amiga ist, egal auf welchem Prozessor. Qualitativ dürfe er auch mit Abstand der beste sein. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
15.07.2006, 18:08 Uhr MaikG Posts: 5172 Nutzer |
>Wie auch immer, ich würde jede wette eingehen, das LAME bei >vergleichbarer Qualität der schnellste mp3 decoder für den Amiga >ist, egal auf welchem Prozessor. Jemand mal Lame auf einem 603e 240MHZ probiert? Blade ist etwas schneller darauf als echtzeit... [ - Antworten - Zitieren - Direktlink - ] |
|
15.07.2006, 18:28 Uhr bubblebobble Posts: 707 Nutzer |
Bist du dir sicher, dass die Einstellungen von Blade Sinn machen ? Echtzeit auf 200MHz erscheint mir zu schnell. Ist denn die 68k Version von Blade auch so schnell (entsprechend auf dem 60er scaliert) ? Auf WinUAE würde ich sagen, dass Blade wesentlich langsamer als LAME ist, und LAME ist bei mir noch etwa 2x Echtzeit bei 1,4GHz. Aber ich habe möglichweise nicht die neueste Blade version getestet ,ist schon eine weile her. -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
16.07.2006, 09:34 Uhr platon42 Posts: 400 [Ex-Mitglied] |
Zitat: Stimme Dir voll zu. Ich würde niemand zu etwas anderem raten als zu LAME. Wobei man die Parameter seinen Bedürfnissen am besten selbst anpasst. Wichtig im Bezug auf Geschwindigkeit ist auch, dass man die Auto-Gain Berechnung deaktiviert -- nur wenige Programme werten diese Info überhaupt aus und kein HW-Decoder. Außerdem LAME vor allem für VBR encoding optimiert. CBR geht entsprechend um Faktoren schneller, kann ich aber *niemanden* empfehlen (auch nicht mit Bitraten >=224kbit). (Bei meinen Tests würde ich immer noch zu --vbr-old tendieren (obwohl langsamer), als zu --vbr-new. Ich hatte bei einigen Files massive Größen- und Qualitätsunterschiede). Auch würde ich zu -k raten, trotz der Warnung, dass dies "ringing & twinkling" bedeuten kann. MP3s, die bei 16KHz abgeschnitten sind, sind für die Tonne. Wenn ich am G4@1GHz mit -q 0 encode, sinkt die Geschwindigkeit auf etwa 1/5 von -q 1 (wobei das im Normalfall bei meinen Einstellungen in etwa Echtzeit ist)... Jedenfalls was ich sagen wollte: Es ist alles eine Frage der Einstellung. Wenn man kleine Files (bei mir im Durchschnitt 110-140kbit/s) mit guter Qualität haben will, die man zur Not evtl. wieder auf CDDA zurückspielen können möchte, dann muss man halt ein wenig Zeit investieren. -- -- Best Regards Chris Hodges [ - Antworten - Zitieren - Direktlink - ] |
|
18.07.2006, 10:46 Uhr Micha1701 Posts: 938 Nutzer |
BTW, hatte was beim kompilieren vergessen einzustellen und nun ist die lib auch um einiges schneller, hier mal ein Vergleich: Encodierung eines 3:07 Min Waves nach MP3 mit 128kBit, 44,1Khz in Stereo LAME V3.97b - 0:42 Min Blademp3.library - 1:56 Min getestet wurde auf WinUAE1.2 mit eingeschaltetem JIT auf WinXP mit P4@3Ghz. Die Werte lassen sich dann schon sehen, oder? Werd noch ein wenig an der Lib feilen und sie dann demnächst online stellen. -- Micha http://www.Silicon-Wizards.com [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > BETA Version der blademp3.library fertig - bitte testen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|