amiga-news 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:
Original von Mirko_Naumann:
@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.

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.


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:
Original von Der_Wanderer:
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.


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:
Original von bernd_roesch:
Bei jeder qualität mehr halbiert sich die speed in etwa.Weil dann doppelt soviele Bänder der Fourier transformation zu berechnen sind


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:
Original von platon42:
Und wer MP3s ohne -k encodiert ist selber Schuld.


WARNING: -k is obsolete.

Ah ja...


--
:boing: AmigaWorld - Amiga Support Network
:peggy: PegasosForum - Pegasos Support Forum & Community

[ - Antworten - Zitieren - Direktlink - ]

03.06.2007, 19:28 Uhr

platon42
Posts: 400
[Ex-Mitglied]
Zitat:
Original von DJBase:
Zitat:
Original von platon42:
Und wer MP3s ohne -k encodiert ist selber Schuld.


WARNING: -k is obsolete.

Ah ja...


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 © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.