Re: Kodek systemowy MP3 - podmieniać?

Użytkownik "Wiktor S." <wswiktorSP@Mpoczta.fm> napisał w wiadomości
news:eama8a$620$1@news.onet.pl...
> > muzyki. Wyszło mi, zę do ok. 20-25 % dzisiejszej objętości zwykłego
> > MP3, ale będzie to okupione dużo większą moca obliczeniową potrzebną
> > do działania kodeka.
>
> W jaki sposób przeprowadziłeś taki szacunek?

Po trochu z tego, co daje MP3Pro, po trochu z innych kodowań dźwięku, trochę
też z przeprowadzania różnych prób np. dla jednej prędkości różne ustawienia
jakości kodowania. Zatem część np. można osiągnąć matematycznie, zwiększając
siłę obliczeń, etc. Wiadomo, ze nie za darmo. Teraz połączyc różne metody, SBR
też nie odrzucam całkowicie, odpowiednio powiązać, bo może przy okazji da sie
pewne obliczenia połączyć w całość, co mogłoby oszczędzić trochę czasu przy
liczeniu... Zresztą, chodzi mi właśnie po głowie, że jest jakiś format
kodowania dźwięku, czy obrazu, nie pamiętam, gdzie dekodowanie może być
realtime, ale jeden kawałek koduje się kilka godzin... Mogę kręcić, ale takie
coś mi pamięć podsuwa.

>
> > Tak, ze realnym wydaje mi się zejście do
> > przepływności 24-32 kbps, przy zachowaniu jakości 128 kbps MP3.
>
> Raczej wątpię, chyba że opracowany zostanie algorytm oparty na zupełnie
> innych założeniach, niż wszystkie obecnie istniejące.

Też to wziąłem pod uwagę.

Podrzucę teraz trzy algorytmy, program w starym, choć nadal używanym
powszechnie BASICu, dla starych (ale niekoniecznie) komputerów 8-bitowych.
Służą temu samemu celowi, a krótka analiza wystarczy, aby się zorientować,
który z nich działą najszybciej, najekonomiczniej... Zadaniem programu jest
policzenie ilości komórek pamięci o danej wartości (od 0 do 255) w całym
(65536 bajtów) obszarze adresowym.

Na początku deklaracja tablic:
5 dim b(255)

1)

10 for e=0 to 255
20 for o=0 to 65535
30 if peek(o)=e then b(e)=b(e)+1
40 next
50 next
(lub 40 next:next)(bez linii 50 - nie ma)
(lub 40 next o,e)(bez linii 50 - nie ma)

2)

100 for o=0 to 65535
1000 if peek(o)=0 then b(0)=b(0)+1
..
..
..
1255 if peek(o)=255 then b(255)=b(255)+1
1300 next

Prawda, ze powyższe przykłądy są głupie?
Tymczasem wystarczy zrobić tak:

3a)

10 for o=0 to 65535
20 b(peek(o))=b(peek(o))+1
30 next

lub tak (bardziej elegancko)

3b)

10 for o=0 to 65535:e=peek(o)
20 b(e)=b(e)+1
30 next

Algorytm trzeci, nie dość, że najprostszy, to nie musi sprawdzać niczego
instrukcją "IF", a także działą najszybciej ze wszystkich, bo realizuje tylko
jeden obieg jednej pętli. A jak ktoś chce, to można wszystko upchnąć w jednej
linii.

Wyprowadzenie wyników niech każdy już sam sobie dorobi :)

O co mi chodzi - aby zrobić z dzisiejszymi algorytmami kodowania coś takiego,
jak ja w BASICu tu przedstawiłem. Naczytałem się w gazetkach z lat 80.
najdziwniejszych algorytmów, porównywalnych rozsądkowo z 1 i 2, a tych z 3a i
3b mało było... A jak widać, nawet identyczny algorytm (3a i 3b) można różnie
zrealizować.
Przestałem już nawet marzyć o tym, by nasze Windy NT (i inne też) Kochane były
przez M$ tak pisane... Patrz Vista...

Mam nadzieję, że zrobią coś takiego dla kodowania dźwięku. Znacznie szybciej,
znacznie chudziej, a conajmniej tak samo dobrze.

-- 
LH
Zanim ogłosisz w złym miejscu: http://www.usenet.pl/nospam/simple-polish.htpl
Zanim zawołasz na GG: http://zanim.napiszesz.prv.pl
Zanim zadasz pytanie na grupie dyskusyjnej: http://rtfm.killfile.pl