| Summary: | Parser prematurely exits when hitting a null tag | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] taglib | Reporter: | mike smithwick <msmithwick> |
| Component: | general | Assignee: | Scott Wheeler <wheeler> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
This is one that I've thought about off and on for a while and for the moment I've decided not to apply. Most of those sorts of checks aren't there just to be pedantic and follow standards, but to try to detect corrupted files before the parser gets confused. If this is something that you're really seeing often, first, please try to report it to the MusicMatch guys and see what they come back with -- let me know the results of that and then I'll see if there's maybe a happy medium, but if this is happening on, say, one file in 1000 tagged with MusicMatch then it's really not worth giving up a sanity check over. |
Version: 1.4 (using KDE Devel) Installed from: Compiled sources Compiler: MS VC 7 OS: MS Windows The MusicMatch (ugh!) Tag editor can produce completely NULL tags. That is, a tag with 6 bytes null header info, and 0 length data. By definition, a tag field must have 1 byte of data. Taglib will bail out completely when it comes across one of these bad tags and all successive fields will be skipped. It should just ignore the bad field and move to the next one. The relevant code is in id3v2tag.cpp, about line 436 (in 1.4). We changed the code: if(!frame) return; To: if(!frame) { frameDataPosition += Frame::headerSize(d->header.majorVersion()); continue; } And it seems to work fine.