A problematic MP3 file was found in the 'wild' that would not playback using the MME. The same file is recognized and does playback on Windows from VLC or Windows Media Player. The file in question was not recognized by iTunes on Windows however.
In the MME, the following errors were encountered during the second pass of synchronization for the file:
-----
Sep 13 00:54:52 5 27 0 MME:mss_fsrecurse_sync_metadata(203): msid=3
-- Second PASS --
Sep 13 00:54:52 2 20 1 io-media-generic/trackplayer: Error 10004:
Sep 13 00:54:52 2 20 1 io-media-generic/trackplayer: Couldn't find a
parser for '/fs/usb0/test.mp3'
Sep 13 00:54:52 2 27 200 MDP:metadata_get(756): Failed
iom_get_track_info, errno = 5
Sep 13 00:54:52 3 27 200 MDP:mdp_mgr_metadata_get_int(1093): Error
getting metadata for group 00000002 from "/fs/usb0/test.mp3": An external
resource call used by the MDP failed. (10).
Sep 13 00:54:52 3 27 0 MME:_mss_bfsrecurse_sync_file_2(547): No
metadata parser found for "/fs/usb0/test.mp3".
Sep 13 00:54:52 5 27 0 MME:mss_fsrecurse_syncplaylists(503): msid=3
-- Third PASS --
-----
The following information was extracted from the problematic MP3 file:
- The file contains a ID3 tag (version 2.3.0) of length 0x1960 (6,496 byes).
- The start of the MP3 data (the first frame) is at 0x7060 (28,768 bytes).
- The second frame of MP3 data is at 0x72d2 (29,394 bytes).
- The file also contains an ID3 tag (version 1) of 128 byte length at the end of the file.
This was all confirmed in a hex editor referencing the ID3 and MP3 data format and header specifications. Thus there is a gap of length 0x5700 (22,272 bytes) between the end of the ID3 tag and the beginning of the MP3 data. Upon further investigation, this 'gap' consisted of another ID3 tag (version 2.4.0) which must have been created or inserted by some tool previously. Basically this is the problem and why the file is not recognized as a correct MP3 file by the MME and playback does not occur.
An "MP3 validator" program was used to look at and 'repair' this MP3 file. It detected the same problem noted above in the file and upon selecting repair, it basically stripped out the interim bytes between 0x1960 and 0x7060 (the second ID3 tag) which subsequently made the file playable.
For reference purposes the software used was:
http://mp3val.sourceforge.net/
The reason that this problematic file was not recognized or played back by the MME is that the mpeg parser does not scan far enough when looking for the first mp3 headers to identify the file as a valid MP3 file. Specifically the parser scans up to the following byte offset looking for 2 consecutive mp3 frame signatures:
id3tag_size + MM_MP3_SCANSIZE + MAX_MP3_FRAME
id3tag_size - In this case is 0x1960 (6,496 bytes) as noted above.
MM_MP3_SCANSIZE - This is defaulted at 8192 bytes but can be changed (more info below).
MAX_MP3_FRAME - This is calculated to be 2884 bytes and represents the maximum possible MP3 frame size.
In this case that calculation leads to 6,496 + 9,192 + 2,884 = 17,572 which doesn't include the first two MP3 frames (at 28,768 and 29,394).
While the default MM_MP3_SCANSIZE value is 8192 (bytes) the value can be changed to a different value by setting it as an environment variable. The minimum size for this value is 2048, and setting a value less than this will result in a value of 2048 being used.
For example with the following setting(made before starting the MME) the mp3 file in question is recognized and plays back without problems:
# export MM_MP3_SCANSIZE=32768
The effect of setting this value to something greater than the default is that that much additional data will be read into memory during the synchronization phase where metadata is read in and the MP3 file is validated. This of course will increase the time spent in the synchronization pass. The actual quantitative effects would have to be measured on the target platform.
NOTE: This entry has been validated against the SDP version listed above. Use caution when considering this advice for any other SDP version. For supported releases, please reach out to QNX Technical Support if you have any questions/concerns.
Please contact us with your questions or concerns.
BlackBerry uses cookies to help make our website better. Some of the cookies are necessary for the proper functioning of the website while others, non-essential cookies, are used to better understand how you interact with our website and to make it better.
