logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

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

29 Paź 2006 20:38 5517 15
  • #1 3166943
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #2 3167310
    Konto nie istnieje
    Konto nie istnieje  
  • #3 3168332
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #4 3169121
    shg
    Poziom 35  
    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.
  • #5 3169460
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #6 3171292
    shg
    Poziom 35  
    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):
    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.
  • #7 3172220
    Konto nie istnieje
    Poziom 1  
  • #8 3172480
    shg
    Poziom 35  
    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:
    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ć.
  • #9 3172518
    Konto nie istnieje
    Poziom 1  
  • #10 3172639
    shg
    Poziom 35  
    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.
  • #11 3172766
    Konto nie istnieje
    Poziom 1  
  • #12 3207128
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #13 3207736
    shg
    Poziom 35  
    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.

    tablica[rozmiar_x][rozmiar_y]

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

    Odwołanie się do elementu tablicy dwuwymiarowej:

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

    lub:
    tablica[y * rozmiar_x + x]

    W zależności od tego w jaki sposób przechowywane są w pamięci tablice wielowymiarowe.
  • #14 3207824
    Konto nie istnieje
    Poziom 1  
  • #15 3292587
    ogr
    Poziom 15  
    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.
  • #16 3293857
    Konto nie istnieje
    Poziom 1  
REKLAMA