Speakerplans.com Homepage
Forum Home Forum Home > Other Chat > Computer Talk
  New Posts New Posts RSS Feed - Mp3 cleaner/extractor/encoder comparator
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Mp3 cleaner/extractor/encoder comparator

 Post Reply Post Reply
gen0me View Drop Down
Young Croc
Young Croc

Joined: 20 February 2016
Location: UK
Status: Offline
Points: 990
Post Options Post Options   Thanks (0) Thanks(0)   Quote gen0me Quote  Post ReplyReply Direct Link To This Post Topic: Mp3 cleaner/extractor/encoder comparator
    Posted: 02 June 2019 at 7:10pm
Some time ago I thought about piece of software that will make mp3s work on CDJ1000mk3. So this was my motivation. I cant test it now. Anyway writing it turned out to be harder than expected. Because the structure of mp3 files may be so different. Frames can be packed in more or less sophisticated way. Im sure you can hear on many early released products that they eat some frames etc not keeping bpm. My tv has this, cdjs 2000 mk1 had this.. I think foobar never let me down in here. So with the above, a lot of reverse engineering is involved. The papers I found on the web were incomplete and typos made it even harder. So except just writing the software I wrote plenty of debugging tools. So the software seems to be usefull for comparing different encoders.
So first are 2 numbers-indexes. First number is the index of frame after initial sorting. Second one is the index number of frame after all sorting was done taking in account correlation between frames.
i - is the index of Byte in opened file where header is located. If you open mp3 file in hex edit -> go to (dec) and write i, you will find this header.
flb is confusingly used as frame length in Bytes but ... such thing doesnt exists... so it is distance in Bytes to next header which is calculated from sampling rate, bitrate and mpeg/layer used. Naturally if i+flb is equal to i of the next frame is the basis criterion of frame validity.
bitrate, sampling rate, flb
negative offset - from header to first Byte of data. This is where the frame really starts.
pre_h_valid is for my debugging. If you find here unexpectedly high value it will be interesting subject for analysis. You can always drop me file to: https://drive.google.com/folderview?id=1Wg_sGTf-3wGS-7eu0Ap8n33x5wL2jov-
pad - is the padding
fr_s - frame size - its real size from decoder point of view. So entire coding data + header rounded to full Byte
m/s - mono/stereo
val - if frame was considered valid by my reluctant algorithms
When you dig into menu and activate Show frame data. Every 1 mp3 frame has 1 header with side info(optionally crc check*). And in each frame there are 2 granules if it is a mono frame and 4 granules for stereo frame. With Show frame data on you(in mpeg layer 3 frame consists 1152 samples so 1152/2 samples per granule) can see after frame param info, info about granules. Length of each granule in bits. Following is hex data of the frame divided into granules and (header+side info). Now if you look where the frame data ends it will tell you how much unused space is left to following frame. This would be first school criterion for comparing encoders. There are different encoders. Some use oversized bitrate and leave empty space after data ends. Better use negative offset value of next frame to compensate for this. Many use various bitrate which changes calculated distance between frame headers. VBR is already implemented. There is one more thing called Free bitrate. This option currently doesnt work but files encoded this way are very unpopular. 1% would be a huge overestimation.

*In reality crc check only tells if entire data in a frame was corrupted or not. I skipped crc check. It is implemented in algorithms based on lengths but I havent calculated the crc itself. All in all it only tells info to decoder if frame should be played or if previous/following frame should be played instead. Moreover it is really unpopular to do crc checks in mp3 frames.

In menu you can also specify which frames to show.

At this point software works on most of mp3 files. On some it shows few glitches. Out of first 15 tracks I checked 1 failed totally. What now needs some work is the criterion of finding the right frames.
Here is what I got so far:

Should work on everything(Windows/Linux/Android).Uses standard libraries. I currently run it on Cxxdroid on Android.
I cant compile an exe version as my PC is down. Feel free to compile and drop here:
If not ill add it later.
I appreciate every like :)) https//www.facebook.com/genomesoundsystems
Mixes: https://www.mixcloud.com/gen-ome/
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.01
Copyright ©2001-2018 Web Wiz Ltd.

This page was generated in 0.063 seconds.