ID3LIB Bug
|
ID3LIB Bug |
|
|
||
|
Home « Computers « DevBlog | |
Back to: Development Blog Contents
A subtle bug in the ID3LIB open source project triggers some development
On the weekend of 22-Nov-2003 I started writing my own MP3 TAG maintenance application called Onyx MP3 Tagger. Over the previous few years I had tried about a dozen freeware MP3 tagging programs, but most were utterly execrable beyond living belief, clearly written by struggling progreammers who were incompetent or sadly naïve. A few programs were vaguely usable but riddled with weird behaviour and looks. One program was aceptable and I used it for over a year, but when Windows XP arrived it failed totally with a stupid error related to the folder open dialog.
Sick of incompetent freeware, I decided to write my own MP3 tagging application in the .NET framework using C# as the programming language, the ComponentOne True DBGrid as the major control and ID3LIB 3.8.2 as the low-level file worker via interop.
Everything ran smoothly for the first several hours, as the app was basically working, reading MP3 tag frame information into the grid columns and running mock updates correctly. I ran a stress test and loaded 850 MP3 files into the app, but it crashed inside id3lib.dll in debug mode when parsing certain files. After an hour of suffering I discovered that all of the problem MP3 files were VBR (Variable Bit Rate) encoded. I had stepped line-by-line down in the debugger to find that the field vbrheaderdata was being overrun deep inside the mp3_parse.cpp file. I did not have time to find out what maximum length was expected, but this Google search quickly revealed that I was not alone in my suffering:
http://sourceforge.net/tracker/index.php?func=detail&aid=697951&group_id=979&atid=100979 VBR_HEADER_MAX_SIZE value incorrect in mp3_parse.cpp The value of the VBR_HEADER_MAX_SIZE constant is incorrectly computed. Inspection of the calculation of "vbr_header_size" (at mp3_parse.cpp:497) will reveal that it should be 120 bytes, not 116. As a result, data following the "vbrheaderdata" array may be overwritten/corrupted. (In practice, the latter being allocated 116+1 bytes means that real data won't be overwritten due to word alignment.) |
This anonymous poster was quite correct. I had found that a brute force buffer length change from 116 to 256 fixed the problem. I have modified the ID3LIB source temporarily (locally) and hope the problem will be corrected in an upcoming release.
In February 2004 I ceased using the ID3LIB in my Onyx application. I wrote my own ID3 Tag manipulation library called tagnetlib in pure managed C# code. The 
tagnetlib full project is availble for free.
Back to: Development Blog Contents