|
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 - ] |
|
31.05.2007, 19:29 Uhr Der_Wanderer Posts: 1229 Nutzer |
----- 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... ----- @Holger gerade bei 128 kbps macht es Sinn. Denn da muss man sich mehr Mühe geben, die Frequenzen zu packen als bei 192 oder mehr. -- 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, 22:45 Uhr Hennig Posts: 81 [Benutzer gesperrt] |
Zitat: Das meinte ich, das AmigaOS ist aber in der Hinsicht flexibler und noch besser zu bedienen wie Windows unter normalen Bedingungen. Ich stelle dann auch schon mal die Priorität auf klein um besser unter Windows arbeiten zu können. Früher war die Geschwindigkeit sehr wichtig, aber mit immer höheren Takt der CPU und deren ausgefeilteren Technik sind Optimierungen nicht mehr so wichtig. Sprich vielleicht das ganze noch in Assembler.  Daher. es ist toll wenn die CD in MP3 5 minuten früher fertig ist, aber ich mußte eh nicht darauf warten um weiterzumachen am Computer.Altivec, ja sowas meinte ich. MfG Hennig [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2007, 15:09 Uhr CarstenS Posts: 5566 Nutzer |
@Andreas_ B: >> stören die längeren Berechnungszeiten ja nicht [...] > 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 Ich bezog mich bei der Berechnungszeit nur auf die Q-Einstellung. Wie stark die Dauer bei CBR vs. VBR differiert, habe ich noch nicht getestet. -- Tipp der Woche -> http://www.tippderwoche.info.ms [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2007, 15:20 Uhr MaikG Posts: 5172 Nutzer |
>060 3.98a11 (15.02.2007) -> 04:29 Min = 0.480 x Echtzeit Also entweder ist das Testfile eigenartig oder es war UAE im GHZ bereich. Ich hab hier 0,0922x Nena/OR-Ich kann nichts dafür 44khz/16Bit-> 192kb mp3. Gegenüber den letzen Versionen wirklich erheblich schneller, V3.97 bringt allerdings noch ein Tick mehr. [ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 10:55 Uhr platon42 Posts: 400 [Ex-Mitglied] |
Zitat: Halte ich für ein Gerücht. Da kann man ziemlich streng nach psychoakkustischem Modell vorgehen und die Bits auf die Bänder verteilen. Ach ja, ich halte diese ganze Diskussion für müßig ohne definierte Testbedingungen, sowohl für das Input-Material, Compiler-Einstellungen, #defines für LAME etc. Wenn ihr wirklich Geschwindigkeitsgewinn ohne Qualitätsunterschied haben wolltet, hättet ihr längst --noreplaygain verwendet. Ach ja, meine Einstellungen: --noreplaygain -p -h -k -v -V 5 -q 1 --vbr-old --nspsytune --athtype 2 Ich traue dem --vbr-new nicht, da ich teilweise bei einigen Songs einen Faktor 2 Unterschied in der durchschnittlichen Bitrate hatte. Und wer MP3s ohne -k encodiert ist selber Schuld. -- -- Best Regards Chris Hodges [ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 14:52 Uhr bernd_roesch Posts: 364 [Benutzer gesperrt] |
Ich würde aber zu gerne mal lame Werte von nem effika sehen unter Linux oder MOS sehen , ob das schneller als ne Cybppc 604 233 ist. > -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". Ich habe bei q 0 oder q1 noch nie was gehört dass es besser wird.bei 128kb leidet eh ziemlich die stereobreite Da nehm ich lieber 192 kbit. Ich würde aber trotzdem mal spasshalber testen wie lange es mit q1 dauert.evtl haben die einfach in den neuen lames die setting für q 0 rausgenommen rausgenommen. Bei jeder qualität mehr halbiert sich die speed in etwa.Weil dann doppelt soviele Bänder der Fourier transformation zu berechnen sind kommt bei deinen werten ungefähr hin, dass 3.93 anscheinend bei q 0 und q1 keinen Unterschied macht Dann ists besser wenn du tatsächlich bei q 0 q1 hörst dass es besser klingt, wenn du nen alten lame nimmst. [ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 14:56 Uhr Andreas_Wolf Posts: 2980 Nutzer |
> Also entweder ist das Testfile eigenartig oder es war UAE im GHZ > bereich. ...oder du hast nicht verstanden, daß die Executables auf MorphOS getestet wurden. [ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 15:29 Uhr platon42 Posts: 400 [Ex-Mitglied] |
Zitat: Ouch. Das ist ja hier wie beim Monte Carlo-Prinzip. Einfach mal ins Blau feuern, vielleicht fällt ja die richtige Antwort vom Himmel. An den Bändern ändert sich rein gar nichts. -q0 und -q1 wählen nur andere Algorithmen aus (nicht nur auf FFT beschränkt), die verschieden genau arbeiten. Manchmal hilft es schon, die Docs zu lesen. Manchmal muss man sich aber auch durch den Sourcecode quälen, um die Wahrheit zu finden. -- -- Best Regards Chris Hodges [ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 17:56 Uhr DJBase Posts: 3354 [Ex-Mitglied] |
Zitat: WARNING: -k is obsolete. Ah ja... --  AmigaWorld - Amiga Support Network PegasosForum - Pegasos Support Forum & Community[ - Antworten - Zitieren - Direktlink - ] |
|
03.06.2007, 19:28 Uhr platon42 Posts: 400 [Ex-Mitglied] |
Zitat: Tatsächlich: Seit 3.98beta1 ist -k defaultmäßig aktiviert. Lustig ist dabei, dass in der Auflistung der Kommandozeilenoptionen immer noch "not recommended" drin steht (ja, höchstens für CBR). Wenn natürlich der Tiefpassfilter in der neuen Version automatisch deaktiviert ist, kann das auch einige Geschwindigkeitsunterschiede erklären. -- -- Best Regards Chris Hodges [ - Antworten - Zitieren - Direktlink - ] |
|
04.06.2007, 15:37 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Bernd, @Platon42 Ihr wisst glaube ich nicht ganz, wie das MP3 format funktioniert. Ich wüsste es auch nicht so genau, wenn ich es nicht in meiner Vertiefungsprüfung im Info Studium hätte erklären müssen ;-) (und jetzt unterrichte ich so was ähnliches an einer deutschen Elite-Uni ;-) Also im groben funktioniert es so: Man nimmt das Audio Singal in der Zeit-Domain (also so wie es gesampelt wird), wirft eine Fensterfunktion drüber (ist jetzt mal nicht so wichtig) und wandelt es mit der FFT in das Spektrum um (Frequenz Domain). Die Fenstergröße ist (normalerweise) immer gleich gross, egal welche Bitrate, die FFT hat also immer gleich viele "Bins" und dauert immer gleich lange. Jetzt versucht man möglichst geschickt Frequenzen/Phasen rauszuwerfen, ohne das der Mensch das merkt. Wie man das genau macht, bestimmt im wesentlichen das Psycho Akustik Model, der wesentliche Teil wo sich die Encoder unterscheiden und was Zeit kostet. Z.B. wirft man Frequenzen raus, - die sehr leise sind - die nahe beieinander liegen (Frequency Masking) - die zeitlich einer ähnlichen Frequenz folgen (Time Masking) etc. Des weiteren teilt man das Spektrum in eine sog. "Mel" Scala ein, die eher der Auflösung des menschlichen Ohres entspricht, als das lineare Spektrum. Also bessere Auflösung zwischen in den mittleren Frequenzen (wo auch unsere Sprache "zufälligerweise" liegt), schlechtere Auflösung in den Bässen und Höhen. Zu guter Letzt zieht man noch das Spektrum vom vorherigen Block ab (in der Annahme dass es ähnlich ist und man viele 0er bekommt), und quantisiert man noch die einzelnen Werte mehr oder weniger stark, je nachdem wie stark das auffallen wird. Am ende packt man das alles wie ein zip Archive, und man erhält einen "Block". (verschont mich mit Haarspalterein, ich habe es einfach gemacht und auf die wichtigsten Details beschränkt) => kbps je kleiner die Bitrate, je länger braucht der Decoder um die "wichtigen" Frequenzen herauszufiltern, und je wichtiger ist die Strategie dabei (Psychoakustik Model) D.h. bei hohen Bitraten unterscheiden sich die Encoder qualitativ immer weniger, und sind auch tendentiell schneller. => VBR ist sinnvoll, denn nicht jeder Block ist gleichschwierig zu packen, z.B. wenn nur wenige Sinustöne oder nichts zu hören sind (wenige Frequenzen werden benötigt), im Kontrast zu weissem Rauschen (so gut wie alle Frequenzen werden benötigt). => -k Der Encoder wendet dann keinen Tiefpass Filter auf das Singal an. Das ist dann sinnvoll, wenn der Enocder gut genug ist und die bitrate hoch genug um das ursprüngliche Signal gut genug zu approximieren. Der Tiefpass filter ist dann sinnvoll, wenn das nicht mehr geht. Dann werden im Hohen Bereich Frequenzen entfernt, die man nicht mehr encodieren muss. Das signal wird zwar dumpfer, klingt aber möglicherweise besser, weil man nicht dieses Blubbern bekommt, was man hört wenn zu viele Frequenzen wichtig sind die man nicht in die bitrate hineingepackt bekommt. Generell bin ich aber kein Freund dier -k funktion, denn die weiss ja nicht was für ein Signal man "reinfüttern" wird. Z.b. zum Encodieren von Sprache benötigt man viel weniger kbps als bei Musik, und die wird dann dumpf, obwohl man sie locker ohne Tiefpass encodieren kann. -- 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 - ] |
| 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. |
|
