|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > MorphOS > Neues OS4 Lame bringt Rekordspeed!!! | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
29.05.2007, 17:11 Uhr Mirko_Naumann Posts: 715 Nutzer |
In den Amiga-News stand, daß es im OS4 Depot ein neues Lame gibt. http://www.os4depot.net/share/audio/record/lame.lha Da schon vorherige OS4 Versionen von Lame wunderbar mit PatchLoadSegOS4 unter MorphOS liefen, hab ich natürlich gleich die neue getestet. Und - oh Wunder - es geht ab wie eine Rakete  * Konfiguration * Rechner: Pegasos2 1 GHz G4, MOS 1.4.5., Ambient 1.43, OS4Emu 1.9 Testfile: Größe 22337 KB WAVE 44.1 KHz GUI: TheMPegEncGUI_Lame V2.63 Lame: 1.) OS4 Version 3.98b3 (25.05.2007) 2.) OS4 Version 3.97 (25.11.2006) 3.) MOS Version 3.97b2 (30.08.2006) MP3: Qualität=0 JointStereo 44.1 KHz 128 KBps * Speed * 1.) 1:08 Min (neuestes OS4 Lame) 2.) 1:59 Min (älteres OS4 Lame) 3.) 2:44 Min (MOS Lame) Grob über den Daumen gepeilt ist das knapp doppelt so schnell wie die alte Version und knapp 3 mal so schnell wie die MOS Version. Na wenn das nichts ist! [ - Antworten - Zitieren - Direktlink - ] |
|
29.05.2007, 17:30 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Mirko LAME bei Quaität 0 zu vergleichen macht keinen Sinn, da sind viele experimentelle Dinge angschaltet, die sich von Version zu Version komplett ändern können. Wenn schon, dann musst du LAME bei einer vernünftigen Einstellung testen, ich würde vorschlagen mit den Default Parameter, die ergeben bereits eine sehr gute Qualität. Du kannst auch mal mit "-f" testen, dann ist zwar die Qualität nicht so gut, aber du siehst wie schnell der Grund Algorithmus ist, weil jeglicher Schnickschnack abgeschaltet ist. Evtl. kann man auch mit -h testen, da sind alle sinnvollen Qualitäts Einstellungen drin. Aber -q 0 ist zu viel! -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
29.05.2007, 17:40 Uhr AmigaPapst Posts: 980 Nutzer |
@Mirko_Naumann: Hast du mal die neueste G4 Version getestet, diese müsste noch schneller sein. Allerdings weiss ich nicht ob diese Verson auch unter der OS4emu läuft. http://os4depot.net/index.php?function=showfile&file=audio/record/lame-g4.lha --  AmigaOne XE G3 750FX 800Mhz/Sil0680/512MB + Radeon 9000 128 MB + AmigaOS 4 A4000T CyberstormPPC 604e 200Mhz/060/128MB + CybervisionPPC 8MB + AmigaOS 3.9und viele Amigas mehr... [ - Antworten - Zitieren - Direktlink - ] |
|
29.05.2007, 18:12 Uhr MaikG Posts: 5172 Nutzer |
Ich will ja nicht unken aber in 1:08 Minuten macht mir meine CPPC ein MP3 mit BladeEnc 2:10 Min Audio(Wave 44.1 16 Bit). [ - Antworten - Zitieren - Direktlink - ] |
|
29.05.2007, 18:43 Uhr Der_Wanderer Posts: 1229 Nutzer |
Wie ich schon geschrieben habe, die Speed ist überhaupt nicht representativ, weil alle möglichen Experimentellen Sachen angschaltet sind. Die kann sich locker verdoppeln oder vervierfachen, je nach qualitäts settings. Deshalb würde ich default werte oder schnelles encoding wählen. BTW, blade ist qualitativ auch deutlich schlechter, etwa gleichzusetzen mit LAME bei "-f" option. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 14:39 Uhr Wishmaster Posts: 140 Nutzer |
@MaikG: Menschenskinders, du Witzbold, ein sau dämlicher Kommentar. Hier geht es um Lame und nicht um diesen Schrott namens BladeEnc. -- Pegasos MorphOS [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 16:26 Uhr Mirko_Naumann Posts: 715 Nutzer |
Also Lame G4 für Altivec läuft leider nicht an, stürzt aber zum Glück auch nicht ab. Schade, wär interessant gewesen. Hab aber mal noch andere Versionen für 060, 020 und WOS ausprobiert. Das Testfile hat übrigens 02:09 Min Spielzeit. Hier die komplette Zusammenfassung (wenn noch was fehlt, her damit): OS4 3.97 G4 (27.05.2007) -> funktioniert leider nicht OS4 3.98b3 (25.05.2007) -> 01:08 Min = 1.897 x Echtzeit OS4 3.97 (25.11.2006) -> 01:59 Min = 1.084 x Echtzeit MOS 3.97b2 (30.08.2006) -> 02:44 Min = 0.787 x Echtzeit WOS 3.97b (19.10.2005) -> 02:42 Min = 0.796 x Echtzeit 060 3.98a11 (15.02.2007) -> 04:29 Min = 0.480 x Echtzeit 020 3.98a11 (15.02.2007) -> 43:23 Min = 0.050 x Echtzeit Was eure Vorschläge mit geänderten Einstellungen angeht - ich kodiere alle meine MP3's in höchster Qualität, von da her ist es für den Vergleich am effektivsten damit zu arbeiten. Schlechtere Qualität ist zwar schneller (siehe BladeEnc) klingt aber auch schlechter und deswegen nutze ich diese auch nicht zum Kodieren meiner Sammlungen. Wenn ihr mit niedrigerer Qualität zufrieden seid, bitte. Aber ich denke, die Geschwindigkeitsfaktoren sind auch darauf anwendbar. Wie ihr an den Werten erkennen könnt, ist die Geschwindigkeitssteigerung enorm. Grund genug für diesen Thread. Zudem ziemlich interessant! Sagt einiges über die Leistungsfähigkeit der OS4Emu und Trance aus  Wer kennt ähnlich gravierende Beispiele von OS4 Software, die unter OS4Emu läuft, z.B. Videoencoder? [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 16:55 Uhr Mirko_Naumann Posts: 715 Nutzer |
Weil einige unbedingt die Standardqualität wollten, hier die Tests: OS4 3.98b3 (25.05.2007) -> 00:33 Min = 3.909 x Echtzeit MOS 3.97b2 (30.08.2006) -> 00:39 Min = 3.308 x Echtzeit WOS 3.97b (19.10.2005) -> 00:37 Min = 3.486 x Echtzeit Demnach dürften die Optimierungen im Bereich der Qualität=0 stattgefunden haben. Ich bleib jedenfalls bei Qualität=0. [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 17:50 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Mirko Dir muss aber klar sein, dass die "Optimierungen" einfach das weglassen oder austauschen von experimentellen Alogrithmen sind, die möglicherweise sogar kontraproduktiv sind. Mit -q 0 zu encodieren ist totale Verschwendung von CPU Zyklen, und die LAME Versionen sind nicht vergleichbar. Da werden quasi Äpfel mit Birnen verglichen. Nur bei -h, default oder -f kannst du die verschiedenen Versionen miteinander messen, und wie du siehst, kommt da was ganz anderes raus, nähmlich dass die Versionen alle ähnlich schnell sind, nix mehr Rekord Speed. Du wirst niemals einen nennenswerten Unterschied zwischen -q 0 und -h hören. Wenn es so wäre, dann wäre der Algo, der in -q 0 mit dabei ist, auch in -h übernommen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 22:40 Uhr CarstenS Posts: 5566 Nutzer |
@Der_Wanderer: > Du wirst niemals einen nennenswerten Unterschied zwischen -q 0 und -h hören. Stimmt, genauso wie man i.d.R. bewusst auch keinen Unterschied zwischen einem guten MP3 und einer CD hört. Der Klangunterschied wird m.E. aber unterbewusst wahrgenommen, und warum sollte man, wenn man eine CD schon in ein verlustbehaftetes Format konvertiert, dann dort nicht die höchsten Qualitätseinstellungen bei einer ordentlichen variablen Bitrate wählen? Aber hier kommen wir offenbar nicht auf einen Nenner, du hast ja schon öfter angemerkt, dass du mit den Standardeinstellungen von LAME bei CBR ganz zufrieden bist. Ich dagegen nicht, weil es einfach hochwertiger geht.  -- Tipp der Woche -> http://www.tippderwoche.info.ms [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 22:59 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ich habe ja nicht gemeint, dass -h sinnlos ist. Ich encodiere auch meistens mit -h. "-h" schreiben die Entwickler als beste Qualität aus, die noch vernünftig ist. Das entspricht -q 2. Bei -q 0 wird alles aktiviert, was möglich ist, ob es nun tatsächlich Sinn macht oder nicht. Da sind alle möglichen experimentellen Sachen drin, die möglicherweise gar nichts bringen, ausser 4x so lange Encodierzeit. Und da sich das von Release zu Release total ändern kann, macht es keinen Sinn LAME auf diesem Level zu vergleichen. Bei -h werden alle wichtigen Funktionen aktiviert, und die sind dann von LAME zu LAME in etwa gleich, nur so kann man Speed vergleichen. Und wie du siehst, sind bei "vernünftigen" Einstellungen die LAME versionen auch in etwa gleich schnell, was zu erwarten war. LAME wird nicht einfach so mal doppelt so schnell, dafür ist es schon lange viel zu optimiert. Selbst die MMX/3DNow Version unter Windows ist nur geringfügig schneller als die "normale" Version. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 23:02 Uhr Mirko_Naumann Posts: 715 Nutzer |
Also mir gehts eigentlich auch nur um höchste Qualität. Wenn ich was mieses hören will, kann ich mir Dateien aus dem Netz ziehen. Macht aber keinen Spaß. Wer nicht bereit ist, in Punkto Qualität Abstriche zu machen, wird sich sicher darüber freuen, daß es ab jetzt nochmal deutlich schneller geht. Auch schön finde ich, daß wenigstens einiges an OS4 Software unter MOS läuft (und dann noch so gut!). Mit etwas Glück hat dies dem einen oder anderen geholfen, der bis jetzt noch mit einer langsameren Alternative werkeln musste. [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 23:39 Uhr Hennig Posts: 81 [Benutzer gesperrt] |
Tag Die eigentliche Ironie ist dann doch, das sowas heutzutage im Hintergrund ablaufen sollte. Und da spielt doch dann das Betriebssystem wohl eher die entscheidene Rolle.  Wer wandelt heutzutage noch seine CD Sammlung um? Das dann wirklich Zeit in Anspruch nimmt. Würde eine bessere Prozessorunterstützung mehr Speed bringen oder wäre das auch nur sehr wenig? MfG Hennig [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2007, 23:59 Uhr Palgucker Posts: 1342 Nutzer |
@Mirko_Naumann Zitat: Das beißt sich aber mit der recht "läppischen" Bitrate von 128KBit - oder war es nur ein Beispiel? Schon mal Optionen wie "--alt-preset extreme" oder eine der hier beschriebenen Settings benutzt? Gruß Palgucker [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 00:30 Uhr Mirko_Naumann Posts: 715 Nutzer |
@Hennig: Hab jetzt nicht ganz verstanden, was du meinst  Du kannst z.B. bei TheMPegEncGUI die Priorität des Lame-Encoders auf -127 stellen und bequem ganze Listen abarbeiten lassen, während du an anderen Dingen arbeitest. Also für mich ist das genug im Hintergrund. Ich wandle ab und an ganze CD-Sammlungen um, da macht es Sinn, wenn der Encoder gut aber flott arbeitet. Als der PPC meiner CyberstormPPC nicht mehr lief, musste ich trotz 66 MHz 060 stundenlang auf mein fertiges MP3 warten (Qualität=0). Auf dem Pegasos geht das aber angenehm flott. Wenn Altivec laufen würde, könnte das vielleicht noch einiges extra an Geschwindigkeit herausholen. So gibts sonst wohl nur noch mehr Leistung durch Übertakten. Aber wirklich langsam ist es ja nicht. @Palgucker 128 KBit mit 44.1 KHz in Joint-Stereo ist doch ok - zumindest wenn es mit Lame kodiert wurde. Das entspricht in etwa CD-Qualität bei einem 11-tel der Größe. Wenn's wirklich nicht reicht, kommt eben noch VBR dazu. [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 01:57 Uhr L-ED Posts: 391 Nutzer |
Nur nen Tipp … mach es gleich richtig (maximale Bitrate + VBR), wobei für mich persönlich mp3 eh nur noch als alternativ Format (betreffs Musik), eine Option. Irgendwann wenn die Ansprüche steigen (ggf. im Zuge von ,,die Soundhardware/Ausrüstung besser''), hängst dann da und spielst erneut alles wieder rein! Sehe aber ein dass gerade auch für Amiga & Morph OS sicher diesbezüglich auch keine Alternative zu MP3 dann gibt. Formate wie .ogg (Vorbis) oder mcp (Musepack) nicht Spielen, geschweige den Encodieren können (mangels Software)? Wobei bei den heutigen Platten Kapazitäten und Preisen sicher auch FLAC als Archiv Format eine Alternative! (Im Zweifel Qualitativ geht’s nicht besser als von Digital 1 zu 1)[ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 10:51 Uhr Der_Wanderer Posts: 1229 Nutzer |
@LED Es gibt auch die ogg Tools für den Amiga. Aber die Playerunterstützung ist nicht da, weil es keine ogg.library gibt. Evtl. erbarmt sich ja mal jemand, dann gibt sicher sehr schnell ogg Support in allen möglichen Playern. Mit PlayOGG kann man die zwar abspielen, aber der nutzt auch nur die ogg Tools als CLI Tool. Zu der Qualitätsdisukssion: Ihr wollt mich einfach nicht verstehen. -q 0 ist möglicherweise ganz mini mini mal besser als -h. MÖGLICHERWEISE, aber alles was wirklich wichtig für die Qualität ist, ist in -h schon drin. LAME wird deshalb so viel langsamer bei -q 0, weil da experimentelle Algorithem benutzt werden, um zu sehen obs was bringt, die aber natürlich nicht optimiert sind. Für das alltägliche Encodieren ist das aber Verschwendung. Die LAME Docu selbst empfiehlt, -h zu nehmen wenn man die maximale Qualität will. Es kann z.B. sein, dass ein experimenteller Algo rausgeworfen wurde bei der neueren LAME Version, deshalb ist das schneller. Das eigentliche LAME, das Sinn macht, ist aber gleich schnell, und da wird sich aber vermutlich nicht mehr viel tun, das ist schon sehr gut optimiert. Wenn du bessere Qualität willst, dann ist es besser auf 160kbps oder 192kbps zu gehen, das bringt eine tatsächliche Verbesserung, nicht nur eine eingebildete, weil man auf die MP3 länger gewartet hat. LAME ist ein sehr guter MP3 packer, wenn nicht der besste. Bei 128kbps hat man eine ordentliche Qualität, die man in normal-Situationen nicht mehr von CD unterscheiden kann. Wenn man genau hin hört und entsprechendes Audio Material hat, z.B. mit viel Rauschen, dann hört man das aber noch. Bei 192kbps wird aber so gut wie jedes musikalische Signal astrein gepackt, bei 256kpbs auch extrem Material. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 11:43 Uhr CarstenS Posts: 5566 Nutzer |
@Der_Wanderer: > Die LAME Docu selbst empfiehlt, -h zu nehmen wenn man die maximale > Qualität will. Hast du zufällig einen Linki, der das bestätigt? Ich habe bislang nämlich überall gelesen, dass -q 0 der höchsten Qualität entspricht, nicht dass -q 0 experimentelle Einstellungen verwendet. > Wenn du bessere Qualität willst, dann ist es besser auf 160kbps oder > 192kbps zu gehen, das bringt eine tatsächliche Verbesserung Klar. Aber wie gesagt: Ich will das Maximum... Und wenn man die Taskpriorität vermindert, stören die längeren Berechnungszeiten ja nicht - die CPU ist ohnehin größtenteils nicht ausgelastet. -- Tipp der Woche -> http://www.tippderwoche.info.ms [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 11:48 Uhr CarstenS Posts: 5566 Nutzer |
@L-ED: > Nur nen Tipp … mach es gleich richtig (maximale Bitrate + VBR) Das ist auch mein Prinzip. Dank VBR erhält man dann Dateien, die gerade mal doppelt so groß sind, verglichen mit 128 KBit CBR - und das bei allerhöchster Qualität. > wobei für mich persönlich mp3 eh nur noch als alternativ Format > (betreffs Musik), eine Option. Tja, da MP3 mit Abstand am besten unterstützt wird, sehe ich dazu derzeit leider keine Alternative. Ich habe früher mal mit Ogg-Vorbis und WMA9 experimentiert, die bei identischer Bitrate deutlich besser klingen, bin aber aufgrund der MP3-Verbreitung schnell dorthin zurückgekehrt. Und mit den genannten Einstellungen ist MP3 m.E. okay. -- Tipp der Woche -> http://www.tippderwoche.info.ms [ Dieser Beitrag wurde von CarstenS am 31.05.2007 um 11:50 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 11:56 Uhr Bjoern Posts: 1730 Nutzer |
Zitat: AFAIK heißt -h höchste Qualität bei eingestellter Bitrate, das ist ein Unterschied. Zitat: Ich denke nicht dass man die Bitrate von MP3, WMA und OGG direkt vergleichen kann. Ein Ogg-File mit identischer Bitrate würde größer werden als ein entsprechendes Mp3-File. Du kannst also m.E nicht an der Bitrate von einer Ogg-Datei auf die Bitrate einer Mp3-Datei schließen weil das eben ganz verschiedene Formate sind. Gruß, Björn [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 12:38 Uhr Wirbel Posts: 357 Nutzer |
Zitat: Sorry, aber 128KBit ist nicht annähernd CD-Qualität! Ich weiß jetzt nicht, auf welchem Medium Du das vergleichst, aber ich höre sowohl auf meiner HiFi-Anlage als auch im Auto noch Unterschiede zwischen CD und 192 KBit heraus! Im Auto zugegebenermaßen nur bei ausgeschaltetem Motor und auch zu Hause nur bei ausgewählten Stücken, aber 128 KBit als CD-Qualität zu bezeichnen, ist fast schon ketzerisch Aber vielleicht solltest Du auch mal über eine anständige Anlage nachdenken? Wenn Du Deine MP3s natürlich nur auf dem PC hörst (AC97 onboard und Aktivboxen) oder einem Walkman mit handelsüblichen Ohrstöpseln, wirst Du vermutlich selbst bei 96 KBit keinen Unterschied zur CD hören OGG wäre natürlich - schon aus rechtlichen Gründen - ideal! [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 13:46 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Bjoern >> Ein Ogg-File mit identischer Bitrate würde größer werden als ein entsprechendes Mp3-File. Das ist Quark. Bitrate bedeutet, wieviele Bits du pro Sekunde encodieren darfst. (ok, abzüglich dem Header). Wenn ein Musikstück bei gleicher Bitrate also eine größere Datei liefert, dann ist es durch Magie wohl beim Encodieren länger geworden ;-) 1> LAME --longhelp ... -h Same as -q 2. Recommended. Und die müssen es ja wissen ;-) Es gibt noch eine längere Readme, da wird das mit den experimentellen Algos erwähnt. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 14:51 Uhr L-ED Posts: 391 Nutzer |
Also ich würde fast dazu übergehen für das Heimische Archiv nur noch Verlustfreie Formate zu wählen (als USB HD Sicherung liegen meine gesamten CD’s bei mir schon als solches vor). FLAC bietet sich dabei besonders und insbesondere auch für u.a. den Amiga an! Es ist sowohl als auch von der benötigten Rechenleistung her jeweils vergleichsweise leicht zu Händeln. Einzig die Geschichte (neben dem erhöhten Platzbedarf), mit der Portabilität (MP3 Player & Co), spricht etwas dagegen. Und macht bisweilen eine solche Strategie dann wieder auf Systemen wo man noch ein bissel nach zu Verfügung stehender CPU Rohleistung schauen und ggf. Kalkulieren muß, unkomfortabel. (Wo bei Bedarf eben mal nicht so fix aus FLAC ein MP3 gestrickt.) Alternativ Lösung wäre vielleicht hier, für Heimische Zwecke FLAC und nebenbei schon mal auf einer USB Platte das Ganze als MP3 aufbereitet dann mit Lagern zu haben? [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 15:12 Uhr Solar Posts: 3680 Nutzer |
Zitat: Ich muß Dich enttäuschen. /usr/share/doc/lame-3.97/USAGE.bz2: Zitat: [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 15:29 Uhr Der_Wanderer Posts: 1229 Nutzer |
Hm, ich meine das gelesen zu haben. Ich meine auch, dass LAME mal extra switches für Sprach Optimierung hatte, kann da aber nichts mehr finden. Aber das hier bestätigt meine Aussagen teilweise zumindest: > -q 0 and -q 1 are slow and may not produce significantly higher quality. Möglicherweise wurden dann einige Parameter bei der neueren Version heruntergeschraubt, weil sie nichts bringen und nur LAME langsam erscheinen lassen, weil es viele Leute wie Mirko gibt, die ohne Sinn und Verstand einfach -q 0 wählen, nach dem Motto "viel hilft viel". -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 16:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Verschwendung ist ein relativer Begriff. Wenn der Encoder eh schneller ist, als das CD-Laufwerk die Audio-Daten liefern kann, ist es keine Verschwendung, das maximal mögliche zu fordern. Ist die CPU halt nicht so schnell (oder das CD-Laufwerk schneller), sieht man das vielleicht anders. ----- EDIT: Antwort zu CBR160/192 gestrichen Mir war nicht klar, dass die Ausgangsbasis tatsächlich CBR128kBit/s war. Damit macht ja nicht mal -q=2 noch Sinn... ----- mfg [ Dieser Beitrag wurde von Holger am 31.05.2007 um 17:21 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 16:37 Uhr Solar Posts: 3680 Nutzer |
Zitat: --voice Zitat: Sagt Dir das Stichwort "diminishing returns" etwas? Ab einer gewissen Optimierungsstuffe ist jeder weitere Fortschritt halt nur noch mit enormen Aufwand zustande zu bringen. Allerdings will ich nicht ausschließen, daß die Optionen früher mal anders belegt waren. [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 17:22 Uhr Andreas_B Posts: 3121 Nutzer |
@CarstenS >> stören die längeren Berechnungszeiten ja nicht @Holger: >> Natürlich schneller kodiert. Ich würde mich freuen, wenn mir mal einer diese Statements erklären könnte! Wenn ich mit VBR kodiere, dann geht das bei mir wesentlich schneller als wenn ich mit CBR kodiere (bei gleicher Qualitätsstufe). Also beispielsweise schafft mein Rechner eine Kodierung mit 128kBit und maximaler Qualität ungefähr mit 1x Speed, mit VBR und maximaler Qualität aber ca. mit 2,7x Speed. Mache ich einen Denkfehler oder verstehe ich Euch falsch? Würde mich freuen, wenn mich mal jemand aufklären könnte. Ciao, Andreas. [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 17:36 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die Qualität eines mp3's kannst Du bei CBR gar nicht kontrollieren, denn in eine fixe Bitrate kannst Du nunmal nur eine begrenzte Menge an Informationen unterbringen. Du kannst mit der -q Option nur bestimmen, wieviel Zeit der Encoder beim Versuch, das Optimale reinzuquetschen, verbringt. Bei VBR dagegen bestimmst Du tatsächlich ein Maß für die Qualität (-V imho). Mein Statement, das ich inzwischen gestrichen habe bezog sich auf den Fall eines vernünftigen Vergleiches (was hier nicht gegeben war, deshalb gestrichen). Du kannst zwar bei CBR die Rechenzeit mit der -q Option in die Höhe treiben, allerdings ohne Auswirkungen auf die tatsächliche, absolute Qualität (zumindest bei -q besser oder gleich 2 und Bitrate < 160). Bei vergleichbarer gleicher resultierender Qualität ist CBR schneller kodiert, vorausgesetzt, Du hast eben vorher die passenden Optionen gefunden, die ohne überflüssigen Rechenaufwand zu eben jener Qualität führen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2007, 17:51 Uhr Andreas_B Posts: 3121 Nutzer |
@Holger: Danke! [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > MorphOS > Neues OS4 Lame bringt Rekordspeed!!! | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|