Semagic bugfixing: XMPlay music detection
Oct. 8th, 2016 09:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
torkellI'd forgotten just how primitive the string parsing in C is.
One bug in Semagic is to do with the music detection for XMPlay: if a track has an Artistsort field and that happens to be returned before the Artist field, then Semagic will pick up that one instead. Actually it's more fun than that, because it'll actually include a few extra characters and return something like "ort Enigma".
XMPlay provides this information in one massive string where each tag is on its own line and has a tab separating the name and the value. Semagic searches for a tag by comparing the start of each line against the tag name, which is where the bug occurs as if you're only comparing the first 6 characters then "artist" and "artistsort" are equal.
Now, if I was coding this up from scratch I'd parse the entire string and dump it into a hash map. Probably with something like this if I was using Java:
But unfortunately I'm using C and so have to roll my own string manipulation. I also have to do my own memory management which is even more annoying... and I can't be bothered with all that malarkey, so I'll try bodging a fix by checking if the field name is followed by a tab. A quick recompile... and it works!
If anyone's interested, here's the patch (apply it against v1.8.0.1):
Huh. I've spotted another bug - Semagic picks the first matching entry, but there can be multiple ones. In particular if a MP3 file has both ID3v1 and ID3v2 tags then it'll find the ID3v1 tag which could very well be truncated (because somebody thought 30 characters would be enough for anybody). That'll be much trickier to fix without rewriting the string parsing.
One bug in Semagic is to do with the music detection for XMPlay: if a track has an Artistsort field and that happens to be returned before the Artist field, then Semagic will pick up that one instead. Actually it's more fun than that, because it'll actually include a few extra characters and return something like "ort Enigma".
XMPlay provides this information in one massive string where each tag is on its own line and has a tab separating the name and the value. Semagic searches for a tag by comparing the start of each line against the tag name, which is where the bug occurs as if you're only comparing the first 6 characters then "artist" and "artistsort" are equal.
Now, if I was coding this up from scratch I'd parse the entire string and dump it into a hash map. Probably with something like this if I was using Java:
String[] lines = input.split('\n');
for (String line in lines) {
String[] tokens = line.split('\t', 2);
if (tokens.length == 2) {
tagMap.put(tokens[0], tokens[1]);
}
}But unfortunately I'm using C and so have to roll my own string manipulation. I also have to do my own memory management which is even more annoying... and I can't be bothered with all that malarkey, so I'll try bodging a fix by checking if the field name is followed by a tab. A quick recompile... and it works!
If anyone's interested, here's the patch (apply it against v1.8.0.1):
Huh. I've spotted another bug - Semagic picks the first matching entry, but there can be multiple ones. In particular if a MP3 file has both ID3v1 and ID3v2 tags then it'll find the ID3v1 tag which could very well be truncated (because somebody thought 30 characters would be enough for anybody). That'll be much trickier to fix without rewriting the string parsing.
