Mp3 structure. CRC check |
Post Reply |
Author | |
gen0me
Young Croc Joined: 20 February 2016 Location: UK Status: Offline Points: 999 |
Post Options
Thanks(0)
Posted: 25 April 2019 at 7:04pm |
I have this example of Mp3 file. Found it on the web.
I extracted the header into seperate bits. Protection bit = 1. So shouldnt here between header and side info be a CRC check? Why there is not? What is the CRC check really dependent from?
Edited by gen0me - 25 April 2019 at 7:05pm |
|
I appreciate every like :)) https//www.facebook.com/genomesoundsystems
Mixes: https://www.mixcloud.com/gen-ome/ |
|
odc04r
Old Croc Joined: 12 July 2006 Location: Sarfampton Status: Offline Points: 5483 |
Post Options
Thanks(1)
|
An MP3 frame header is 4 bytes only, if it exists (because it is optional and not necessarily written in a given file) the CRC check is the next 2 bytes and the audio data for the frame follows until the frame sync of the next frame is seen.
You have identified the start of the frame correctly given the FF Fx xx xx byte stream so if the CRC were to exist for the frame it would be 7A 86. CRC presence is shown by the setting of bit 16 in the header, which is the last bit of the second byte. Your second header byte is FB which in binary is 11111011. Therefore bit 16 is asserted set and this means according to the MP3 file byte structure that there is no copy protection in the file. So don't waste time trying to compute a CRC check, because it doesn't exist. |
|
gen0me
Young Croc Joined: 20 February 2016 Location: UK Status: Offline Points: 999 |
Post Options
Thanks(0)
|
Right: 1 means no protection, 0 is protected.
How did you figured out the CRC check? I have read: CRC is protecting. "bit 16 to 31 in both the header and the side information" But gonna have to reverse eng it as there is no more explanation.
|
|
I appreciate every like :)) https//www.facebook.com/genomesoundsystems
Mixes: https://www.mixcloud.com/gen-ome/ |
|
odc04r
Old Croc Joined: 12 July 2006 Location: Sarfampton Status: Offline Points: 5483 |
Post Options
Thanks(1)
|
In the past when I have worked with CRCs the check byte is usually the data bytes selected to be part of the CRC calculation sequentially XOR'd with a fixed value. Have a look at the wiki page for CRC, it is quite a specific algorithm but can be implemented with a different series of XOR operations and constant values if obfuscation is required. Sometimes also data byte order is reversed too.
I can't find any concrete examples of mp3 CRC generation algorithms on the net, but there is a lot of code on github etc you can browse to get an idea. Something like https://github.com/okdana/mp3sum is a good start. Failing that you only have 2 double byte bits of data to compute the CRC from, so there is only so many ways of doing it. Here is a good resource on CRC16 calcs - https://www.lammertbies.nl/comm/info/crc-calculation.html I suggest if you really want to learn how it works, either dissect someone else's source or get some valid test data and bang it into various CRC16 implementations until it works. |
|
gen0me
Young Croc Joined: 20 February 2016 Location: UK Status: Offline Points: 999 |
Post Options
Thanks(0)
|
And the thing gets more complicated here... Author mixed somewhere byte with bit.. And side info has variable length depending if frame is mono or stereo. + bits count order. So long story short I am not sure which bits/bytes count to check. I bet it has to do with universal decoding info for frame, but its just a guess.
|
|
I appreciate every like :)) https//www.facebook.com/genomesoundsystems
Mixes: https://www.mixcloud.com/gen-ome/ |
|
Post Reply | |
Tweet |
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |