jid3rL Will Continue
I'm not going to stop development on jid3rL even though I'm working again. I'm determined to get it done, albeit slower than if I were still working on it ten hours a day.
The project has been punctuated by a few major refactors as I learn the domain of the problem. This is often the case in software development, and why the iterative/agile methodology centered on enabling refactoring is so powerful: I don't need to know the whole domain to start, because I'm not designing up front.
But don't forget: to refactor with confidence you need unit tests. Otherwise you will just accumulate regressions you have no idea about. jid3rL already has four hundred unit tests in less than a month. Crazy.
Speaking of unit tests, I've made an additional unit testing suite for jid3rL that tests against real mp3 files. It's up on the build page now. The original unit test suite just unit tests against the API with no mp3 files at all, and is what the jcoverage code coverage metric is based on. This is so the code coverage metric isn't skewed by tests involving files.
There are over forty frame types in the various versions of id3v2 and each has its own arrangement of bytes in the payload after the frame header. I have to parse these bytes to read the frame and also generate the bytes from a frame object to construct a tag for writing. In jid3rL that's done individually in each frame right now, which is a terrible administration headache already (I have less than a dozen frame types implemented) and could be a source of quality problems in parsing and building. Not to mention that unit testing each of these frame types is a major effort and should be centralized.
I was looking through the id3lib C++ source code recently and saw something interesting: all of the frame types are specified as constant structs, and the parser and builder are generalized to take these constants and parse and construct frames based on them. I like this approach and I think I'm going to mimic it, but in jid3rL the frame types will still be classes and not constants.
There are some complicated frame types in id3v2 to watch out for. Some use one field value to determine the lengths of another field. Some have fields a few bits in length appended together which do not fall on byte boundaries. Rather than complicate the generalized parser and builder with these advanced frames I think I will parse/build them separately. We'll see which direction the refactoring takes.
AudioMan itself is temporarily on hold until jid3rL is in a usable state and is relatively stable. I'm not going to take a chance on it because with a serious enough defect jid3rL could seriously damage people's mp3 files. That would be bad. jid3rL is going to be the most highly tested piece of software I've ever written.Posted at August 27, 2004 at 04:53 PM EST
Last updated August 27, 2004 at 04:53 PM EST