[algemeen]probleem met mp3 parsen

[ekoopman]

Hoi allemaal, voor een online radio project moet ik onze verzameling van enkele duizenden mp3's parsen (met name voor de lengte van de nummers). Dit gaat verder prima, met name deze site is erg handig geweest: http://www.id3.org/mp3frame.html.
Nu kom ik bij veel mp3's een blok data aan het begin tegen waar ik helemaal niks mee kan, bijvoorbeeld

code:

   0   00 00 47 00 00 00 00 00 00 08    
  10   e0 00 00 00 00 00 01 1c 00 00    
  20   00 00 00 00 23 80 00 00 00 00    
  30   00 00 00 00 00 00 00 00 00 00    
  40   00 00 00 00 00 00 00 00 00 00    
  50   00 00 00 00 00 00 00 00 00 00    
  60   00 00 00 00 00 00 00 00 00 00    
.....veel nullen....
 380   00 00 00 00 00 00 00 00 00 00    
 390   00 00 00 00 00 00 00 00 00 00    
 400   00 00 00 00 00 00 00 00 00 00

Iemand enig idee wat dit is . Ik parse het nu gewoon door steeds een extra byte te lezen na de headers en dan te kijken of ik al een sync header (12 1'en) vind en dat werkt redelijk, maar lijkt me wat suf. Dit specifieke voorbeeld heeft trouwens geen herkenbare headers op dit blok (bagger ?) na, het eerste frame volgt vanaf de volgende niet geposte byte

[Rataplan]

Na het zien van het url dat je geeft durf ik het bijna niet te vragen, maar is dit niet toevallig een (lege) ID3-tag? En is dat blok data steeds van identieke grootte?

[ Voor 1% gewijzigd door Rataplan op 16-02-2004 23:58 . Reden: b? t! ]

[Marijn_S]

Ik weet niet hoe graag je dit zelf oplost, maar hier zijn best al wat kant en klare scripts voor

Ik doe het al vrij lang met deze code:
http://px.sklar.com/code.html?id=491

Al weet ik niet of dat geschikt is voor ID3, maar of je dat nodig hebt?

[ekoopman]

Rataplan schreef op 16 februari 2004 @ 22:30:
Na het zien van het url dat je geeft durf ik heb bijna niet te vragen, maar is dit niet toevallig een (lege) ID3-tag? En is dat blok data steeds van identieke grootte?

Nee, je hebt twee soorten tags ongeveer, versie 1 en 2, de (oude) versie 1 hangt aan het eind van een mp3, en de versie twee tags hangen aan het begin en zijn duidelijk te herkennen aan ID3 als eerste 3 bytes gevolgd door redelijk leesbare blokken met oa text.

[ekoopman]

Cerberus schreef op 16 februari 2004 @ 22:32:
Ik weet niet hoe graag je dit zelf oplost, maar hier zijn best al wat kant en klare scripts voor

Ik doe het al vrij lang met deze code:
http://px.sklar.com/code.html?id=491

Al weet ik niet of dat geschikt is voor ID3, maar of je dat nodig hebt?

Even dat script doorgekeken en mijn script doet wat dat doet en nog veel meer . Ik zie dat die auteur waarschijnlijk hetzelfde heeft gedaan, hij heeft namelijk een stukje code waarmee hij fijn doorzoeft naar de eerste echte mp3 header (en daarmee in ieder geval id3v2 headers overslaat en ook die vreemde headers die ik vind:

code:

 // Checking to make sure I can find Frame Sync
    while (!feof($fp)) {
            $tmp=fgetc($fp);
            if (ord($tmp)==255) {
                $tmp=fgetc($fp);
                if (substr((decbin(ord($tmp))),0,3)=="111") {
                    break;
                }
            }
    } // eo while

[Rataplan]

Tjah. [google=id3v2 mp3 skip header] levert MP3DetectionIsHard op:

Automated MP3 parsing and detection is a pain. There are lots of variants in the wild (...)

Files do not necessarily start with a MP3 frame header. (...) the MP3 header is NOT guaranteed to start immediately after the v2 tag (if present). Some tools seem to put extra null bytes between the header and the first MP3 frame.

dus ik vrees dat ook jij het moet houden op wat je wél weet:

An MP3 frame header starts with 11 sync bits (0x11111111 0x111?????).

Het lijkt er iig op dat het blok data dat jij aantrof applicatie-specifiek is. Gewoon skippen totdat je het spul hebt dat je wíl hebben.

[ekoopman]

bluh ok . Toch jammer dat een gecomprimeerd formaat als mp3 garbage data kan en mag bevatten. In ieder geval bedankt voor het meezoeken.

[Rataplan]

Kroxigor schreef op 16 februari 2004 @ 23:44:
bluh ok . Toch jammer dat een gecomprimeerd formaat als mp3 garbage data kan en mag bevatten. In ieder geval bedankt voor het meezoeken.

Ik zou zeggen: voel je geroepen, en bouw een tooltje dat alle overbodige rotzooi eruitfiltert, dat zou nog best eens wat ruimte kunnen opleveren. Ik hou me wel beschikbaar voor code review & testing*. Zoniet, dan succes met je radioproject

^{* i.e. commentaar vanaf de zijlijn}