Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Konkrety dekompresji mp3. gdzie znajdę drzewo potrzebne do dekompresji?

atom1477 29 Paź 2006 20:38 5154 15
  • #1 29 Paź 2006 20:38
    atom1477
    Poziom 43  

    W każdym poście na temat kompresji/dekompresji mp3 widzę linki do jakichś stronek dla laików. Wiem na czym polega odchudzanie dzwięku przed kompresją Huffmana i wiem na czym polega sama kompresja ale nigdzie nie widzę żadnych konkretów jak to wygląda w mp3.
    Najbardziej interesuje mnie dekompresja. Może jakieś konkrety?
    Gdzie w pliku mp3 znajdę drzewo potrzebne do dekompresji?
    Mam kilka kodów jakichś odtwarzaczy mp3 w C. Widziałem tam jakieś duże tablice danych. Po co one tam są? Były podpisane jako drzewo. Czy to oznacza że drzewo jest zawsze takie samo? To jest chyba trochę dziwne i dlatego się pytam. Może ktoś ma jakieś kody prostych odtwarzaczy najlepiej w Pascalu (Delphi)?

    0 15
  • Pomocny post
    #2 29 Paź 2006 21:52
    Anonymous
    Użytkownik usunął konto  
  • #3 30 Paź 2006 10:32
    atom1477
    Poziom 43  

    Widziałem już tą stronę.
    Nie ma tam nic konkretnego.

    W zasadzie chodzi mi o samą dekompresję a nie o odtwarzanie. Dane po dekompresji mogą być na przykład zapisywane do pliku .wav

    0
  • Pomocny post
    #4 30 Paź 2006 15:55
    shg
    Specjalista techniki cyfrowej

    Drzewo w kodowaniu Huffmana jest zawsze to samo, a właściwie to jest ich kilka do wyboru, w każdym razie jest statyczne i nie jest przechowywane w skompresowanym pliku, tylko w programie dekodującym.

    Jako takiego dokładnego opisu nie widziałem, w zasadzie wszystko opiera się (mniej lub bardziej) na referencyjnym kodzie źródłowym (ISO). Z tego co pamiętam, to komentarze w tym kodzie ograniczają się do opisu co robi dana funkcja. No ale to jest taka najprostsza (i diabelnie powolna) implementacja, która może też służyć za źródło informacji o strukturze pliku, zwłaszcza że praktycznie nie ma tam żadnych optymalizacji.

    A w delphi jeszcze nie widziałem dekodera, ale wiem jedno, do demonów prędkości to on nie będzie należał :P.

    0
  • #5 30 Paź 2006 17:29
    atom1477
    Poziom 43  

    Cytat:
    Jako takiego dokładnego opisu nie widziałem, w zasadzie wszystko opiera się (mniej lub bardziej) na referencyjnym kodzie źródłowym (ISO). Z tego co pamiętam, to komentarze w tym kodzie ograniczają się do opisu co robi dana funkcja. No ale to jest taka najprostsza (i diabelnie powolna) implementacja, która może też służyć za źródło informacji o strukturze pliku, zwłaszcza że praktycznie nie ma tam żadnych optymalizacji.


    W jakim kodzie? Mówisz chyba o jakimś konkretnym bo przecierz każdy nie będzie powolny. A skoro mówisz o konkretnym to znaczy że być może go masz.

    Skoro drzew jest kilka to skąd mam wiedziec które zastosować? Mam kilka źródeł odtwarzaczy i w każdym jest inne drzewo i co gorsza w jednym to drzewo składa się z liczb całkowitych a w innym z rzeczywistych.

    Co do powolności Delphi to się zgadzam. Ale ja Delphi wykorzystam tylko do przetestowania i uproszczenia kodu. Potem soft pujdzie na jakis szybki mikrokontroler.

    0
  • Pomocny post
    #6 31 Paź 2006 00:24
    shg
    Specjalista techniki cyfrowej

    Przejrzałem moje materiały i widzę, że w zasadzie są dwa takie referencyjne źródła, z Fraunhofer IIS i z ISO.
    Te drugie chyba zawierają też rozszerzenia standardu itd.

    Przejrzyj to: http://www.mpeg.org/MPEG/mp3.html

    W załączniku masz źródła z Instytutu Fraunhofera, nie wiem, czy jest to komplet, czy tylko pliki potrzebne do dekodowania.
    Przed chwilą skompilowałem, sprawdziłem i działa, tragicznie wolne to to nie jest, ale demon prędkości też nie...
    Utwór o długości 40.9s info z nagłówka (to "wypluł" ten dekoder):

    Code:
    HDR:  s=FFF, id=1, l=3, ep=1, br=B, sf=0, pd=0, pr=0, m=0, js=0, c=1, o=0, e=0
    
    layer=III, tot bitrate=192, sfrq=44.1, mode=stereo, sblim=32, jsbd=32, ch=2

    Maszyna testowa: Celeron 433MHz, Linux i gcc 3.3.6. Zdekodowało w 37 sekund.
    Dla odmiany Foobar 2000 na Pentium II 400MHz + win xp dekoduje to w 3.1 sekundy ;].

    Nie wiem, czy mi się wydaje, czy paczki poznikały z serwerów ftp IIS i MPEG. :/

    A to że w jednym odtwarzaczy drzewka są z liczb całkowitych, a w innych ze zmiennoprzecinkowych, to właśnie efekt optymalizacji, tak właściwie te liczby całkowite to raczej to samo co zmiennoprzecinkowe, tylko zapisane jako stałoprzecinkowe.

    Tu masz trochę bardziej szczegółowy opis na podstawie kodu źródłowego, nie wiem które dystrybucja, raczej ISO:
    http://le-hacker.org/hacks/mpeg-drafts/11172-3.pdf
    Jest tam opisana struktura ramki.

    0
  • #7 31 Paź 2006 13:07
    atom1477
    Poziom 43  

    Dzięki!
    W takim razie ja spróbuje zastosować liczby całkowite, bo przynajmniej wiem jakie są (W jednym kodzie sa 2 tablice:jedna z liczbami a druga z ilością bitów która je reprezentuje). A rzeczywiste moga być różnie traktowane przez kompilator (bo w innych kodach nic na ten temat nie pisze, może C++ narzuca jakiś standard ale ja nic o tym nie wiem).

    Jeżeli drzewo jest w odtwarzaczu to wystarczy pozamieniać dane z pliku mp3 na dane z drzewa?

    W czym Ty to skompilowałeś? Dev C++ wywala jakieś błędy.

    0
  • #8 31 Paź 2006 14:30
    shg
    Specjalista techniki cyfrowej

    atom1477 napisał:
    Jeżeli drzewo jest w odtwarzaczu to wystarczy pozamieniać dane z pliku mp3 na dane z drzewa?

    Ano.

    atom1477 napisał:
    W czym Ty to skompilowałeś? Dev C++ wywala jakieś błędy.

    Napisałem przecież - gcc 3.3.6 pod linuksem, kilka ostrzeżeń było podczas kompilacji, ale doszło do końca.

    Takie cuda wypluwa kompilator:
    Code:
    shg@turbozlom:/home/samba/soft/fraunhofer_iis$ make
    
    cc -c -O2 -DUNIX decode.c
    cc -c -O2 -DUNIX musicout.c
    musicout.c: In function `main':
    musicout.c:453: warning: passing arg 3 of `III_dequantize_sample' from incompatible pointer type
    musicout.c:500: warning: passing arg 1 of `__builtin_strncpy' from incompatible pointer type
    musicout.c: At top level:
    musicout.c:543: warning: static declaration for `usage' follows non-static
    cc -c -O2 -DUNIX common.c
    cc -c -O2 -DUNIX huffman.c
    cc -o decode  decode.o musicout.o common.o huffman.o -lm
    musicout.o(.text+0x10ab): In function `main':
    : warning: the `gets' function is dangerous and should not be used.


    Pod windą raczej na pewno z makefile trzeba by wywalić -DUNIX, co jeszcze, to nie wiem, na pewno jakieś specyficzne dla systemów UNIXowych funkcje trzeba by zastąpić.

    0
  • #9 31 Paź 2006 14:41
    atom1477
    Poziom 43  

    Nie zauwarzyłem chyba ;p

    Czyli raczej tego nie skompiluje. Ale to chyba mała strata bo w pliku 11172-3.pdf jest dobry opis dekodowania mp3. Szkoda tylko że po angielsku. Troche rozumiem ale dla przyspieszenia chyba zdobędę jakis translator i to przetłumaczę.

    Ale jednego nie rozumiem. Tam jest opis ramki. I z tego opisu wynika że każda ramka zawiera jakieś ID. A ja w swoich plikach mp3 znalazłem tylko jedno ID gdzies na końcu pliku. Dlaczego?

    0
  • #10 31 Paź 2006 15:14
    shg
    Specjalista techniki cyfrowej

    Cytat:
    ID - one bit to indicate the ID of the algorithm. Equals '1' for MPEG audio, '0' is reserved.

    O to chodzi? Jeden bit na początku ramki zaraz za dwunastoma bitami synchronizacji.

    A to co masz na końcu to jest tag ID3 (wykonawca, tytuł itd.). Tak BTW, to lepiej jak ID3 jest na początku pliku, przyspiesza to (i to znacznie) odczytywanie informacji o utworze, ale za to zapis tych informacji trwa dłużej.

    0
  • #11 31 Paź 2006 15:49
    atom1477
    Poziom 43  

    Rzeczywiście.
    Dopiero pobierznie przeglądałem tego pdfa.
    Dzięki!

    1: W pliku 11172-3.pdf brakuje Annex-ów. Wie ktoś skąd je wziąść?

    2: Zgodnie z opisem w tym pdfie każda ramak zawiera informacje o warstwie, częstotliwości próbkowania, sposobie kodowania Stereo itd. itp. Czy to oznacza że tak w środku mp3-ki można sobie raptem zmienić mono na stereo albo zmienić Layer II na Layer III?

    3: Czy każda ramka ma długość równą n*8? (Czyli czy skłąda się z całych bajtów)

    4: Jak mam rozumieć że początek ramki (syncword) to "111111111111"? Pierwszy bajt FF a drugi Fx? To jest zapisane od MSB do LSB?

    0
  • #12 09 Lis 2006 22:25
    atom1477
    Poziom 43  

    W pliku 11172-3.pdf najpierw jest fragment (2.4.1.7 Audio data, Layer III dla Stereo) :

    Cytat:
    for (ch=0; ch<2; ch++)
    for (scfsi_band=0; scfsi_band<4; scfsi_band++)
    scfsi[scfsi_band][ch] 1 bits
    bslbf


    Więc wynika z tego że scfsi jest dwuwymiarową tablicą (4x2)

    A potem jest:
    Cytat:
    for (gr=0; gr<2; gr++)
    for (ch=0; ch<2; ch++) {
    if (blocksplit_flag[gr][ch] == 1 && block_type[gr][ch] == 2)
    {
    for (cb=0; cb<switch_point_l[gr][ch]; cb++)
    if (scfsi[cb]==0) || (gr==0)
    scalefac[cb][gr][ch] 0..4 bits uimsbf
    for (cb=switch_point_s[gr][ch]; cb<cblimit_short; cb++)
    for (window=0; window<3; window++)
    if (scfsi[cb]==0) || (gr==0)
    scalefac[cb][window][gr][ch] 0..4 bits uimsbf
    }
    else
    for (cb=0; cb<cblimit; cb++)
    if (scfsi[cb]==0) || (gr==0)
    scalefac[cb][gr][ch] 0..4 bits uimsbf
    Huffmancodebits (part2_3_length-part2_
    length) bits bslbfഊwhile (position != main_data_end)
    {
    ancillary_bit 1 bit bslbf
    }
    }


    A z tego wynika że jest jednowymiarowa, i do tego o indexach 0..8.
    Jak więc jest naprawdę?

    0
  • Pomocny post
    #13 10 Lis 2006 04:19
    shg
    Specjalista techniki cyfrowej

    atom1477 napisał:
    1: W pliku 11172-3.pdf brakuje Annex-ów. Wie ktoś skąd je wziąść?

    Z tąd: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=22412
    Niestety z dewizy i to nie mało :/
    Ale z tego co się orientuję, to same tabelki, trzeba by to porównać np. ze żródłami z Fraunhofer IIS. Tabelki są wczytywane z plików w common.c

    atom1477 napisał:
    2: Zgodnie z opisem w tym pdfie każda ramak zawiera informacje o warstwie, częstotliwości próbkowania, sposobie kodowania Stereo itd. itp. Czy to oznacza że tak w środku mp3-ki można sobie raptem zmienić mono na stereo albo zmienić Layer II na Layer III?

    Teoretycznie można, ale się tego nie robi.

    atom1477 napisał:
    3: Czy każda ramka ma długość równą n*8? (Czyli czy skłąda się z całych bajtów)

    Tak
    Cytat:
    frame - Layer I and Layer II: Part of the bitstream that is decodable by itself. In Layer I it contains
    information for 384 samples and in Layer II for 1152 samples. It starts
    with a syncword, and ends just before the next syncword. It consists of
    an integer number of slots (four bytes in Layer I, one byte in Layer II).


    - Layer III: Part of the bitstream that is decodable with the use of previously
    acquired side and main information. In Layer III it contains
    information for 1152 samples. Although the distance between the start
    of consecutive syncwords is an integer number of slots (one byte in
    Layer III)
    , the audio information belonging to one frame is generally
    not contained between two successive syncwords.

    A to ostatnie zdanie, to chodzi o to, że dane audio należące do danej ramki najczęściej nie są w całości umieszczone tylko w tej ramce, ale i w poprzedniej.

    atom1477 napisał:
    4: Jak mam rozumieć że początek ramki (syncword) to "111111111111"? Pierwszy bajt FF a drugi Fx? To jest zapisane od MSB do LSB?

    Tak, a ten 'x' to kolejne bity nagłówka (ID, Layer i protection_bit), średnio to wygodne, ale w końcu to kompresja, więc wszystko trzeba maksymalnie upakować.

    Z tymi tablicami jedno i dwuwymiarowymi to jest taki myk, że one są i tak wszystkie jednowymiarowe. Przestrzeń adresowa większości procesorów jest liniowa i jednowymiarowa (jeżeli chodzi o pamięć danych), więc tak też przechowywane są wszystkie dane. Czyli tak na prawdę tablica składająca się z dwoch wierszy po 4 kolumny przechowywana jest jako 8 następujących po sobie komórek, najpierw pierwszy wiersz, a potem drugi.

    Code:
    tablica[rozmiar_x][rozmiar_y]

    jest równoważne:
    Code:
    tablica[rozmiar_x * rozmiar_y]

    Odwołanie się do elementu tablicy dwuwymiarowej:
    Code:
    tablica[x][y]

    jest równoważne:
    Code:
    tablica[x * rozmiar_y + y]

    lub:
    Code:
    tablica[y * rozmiar_x + x]

    W zależności od tego w jaki sposób przechowywane są w pamięci tablice wielowymiarowe.

    0
  • #14 10 Lis 2006 07:36
    atom1477
    Poziom 43  

    Dzięki!
    Z długością ramek i kolejnością bitów sam sobie poradziłem i napisałem funkcję która zwraca odpowiednią liczbę bitów więc jest troche wygodnie (ale dużo wolniej);

    A z tymi tablicami to też tak myślałem jak napisałeś.
    A wiesz może jak to jest konkretnie z scfsi? [x*size_y + y] czy [x + y*size_x]?

    0
  • #15 04 Gru 2006 10:38
    ogr
    Poziom 14  

    Witam!
    Jesli nie masz jeszcze tych annex'ow to wrzuce je na "elke".
    Probuje rozgrysc ten temat i mam pytanie:
    Gdzie znajduje sie informacja odnosnie numeru tabeli(drzewka)
    wg. ktorego dane zostaly skompresowane?
    Czy dane audio w obrebie jednej ramki skompresowane sa wg. jednej tabeli czy kilku?

    Pozdrawiam.

    0
  • #16 04 Gru 2006 17:08
    atom1477
    Poziom 43  

    Już mam te annexy. Dzieki!

    0
  Szukaj w 5mln produktów