This Time Self-Hosted
dark mode light mode Search

Hitting TagLib’s problems

Continues my work to provide reliable Ruby bindings for TagLib library. Unfortunately this mission is becoming harder with the time, as I find runtime problems that needs to be nailed down and fixed. Sigh.

Let’s start with news updates: since yesterday I moved RubyTag++ from Bazaar-NG to GIT. This move was due to dev.gentoo.org being under heavy load and bzr taking ages to checkout the repository via HTTP; I moved it locally, too, so I do have two complete copies of the repository on the two boxes, and I cross-backup them daily. GIT also seems to be quite faster to work with, too, and has a CIA commit script that does not break every other release 😛 (although it sends an SHA1 instead of a revision number 🙁 ). I had to hack it a bit to make it send my name as commit author, although I might ask Micah to add a rule for my email address.

Now let’s see the problems I’m facing. Some of the problems were actually related to the way bindings are generated. I fixed a couple today, especially related to vararg functions (rather than vararg constructors), after adding a few more test and seeing them fail.

Unfortunately there are still failures that seems to be caused by TagLib. In particular writing to specific tags like ID3v1 or APE tags on mp3 files, or any kind of tag on mpc files seems to merely fail.

First I thought I did call save() functions in the wrong way, but after adding consants declaration support to the generator, that wasn’t the case.

After a whole day writing testcases and running the increasing number of tests over and over, I got to a series of bad conclusions, unfortunately 🙁 Musepack (MPC) support in TagLib is mostly broken: although I didn’t try to actually read the tags (as mppenc does not allow me to set them), trying to write them fails. FLAC support is unstable, a lot unstable: it can’t read tags nor audio properties from a simple FLAC generated on the fly by flac command, although the data is there when I look at it with metaflac; I can write ID3v2 tags but I can’t write v1 or Xiph comments; OggFlac support is incomplete too, as it marks as invalid OggFlac files created without tags in the first place. Ogg Vorbis support seems quite solid tho. And it’s actually a lot simpler to deal with them through TagLib’s API than dealing with ID3v2 tags, for once.

The RubyTag++ testsuite is now over 30 different test, trying to check as much things as possible on the filetypes available. For every file type I wrote at least a “basic” test, where the tag fields are set by the encoder (if it can, so not the case of MPC), a “tags” test (for formats that supports more than one tag type) and a “fields” test (for accessing fields directly through the map) that replaces the “tags” one for Ogg formats, a “fileref” test for FileRef class (that fails for OggFlac files as .ogg extension is always considered Ogg Vorbis), and it’s quite unrealible anyway; and a series of “write” test with the generic tag interface or with the specific interface of the various types of tags. I’m going to add more tests about audioProperties tomorrow, too.

Although Wheeler’s (and the rest of TagLib’s team’s) work is pretty amazing, right now it’s reliable only for reading, and that might be the reason for which there are not much KDE taggers I’m afraid. The API is pretty consistent, the documentation almost errorless, and the code well written. Unfortunately there are many corner cases that were never tested. I think that missing a testsuite have a good amount of cause behind this. If someone wants to write a suite of crosstests against mine, using the native C++ API it would really be useful to have it ran on different TagLib’s versions to make sure that all goes well.

I hope to be able to report the problems I find with a solution on taglib-devel in the next days.

Anyway, I’m absolutely satisfied with my generator script. I’ve refined it more and more after working with RubyTag++ in practice, it now handles correctly vararg functions and constants, it also alias the functions that uses CamelCase capitalization to the ruby_underlined_style (initially by defining more functions, but tonight I made it use the actual alias support in Ruby).

After RubyTag++ testsuite is complete enough, I’ll work on adding a proper testsuite to the generator code, some C++ classes with a description file and some ruby test scripts that checks that functions, constants and similar are correclty defined 🙂

If anybody wants to help me on this project, I’m just waiting your mails 😉

Comments 3
  1. Hi Diego,Make the ciabot.pl send the output of <tt>git describe $rev</tt> instead of just <tt>$rev</tt>. That way you get something like this:

    0.1_beta-g884ec81

    instead of the ugly:

    884ec81028e9ceee7c6db56c9ee0d0cb4348cd5e

    <tt>git describe</tt> just walks the tree until it finds a commit that has been tagged and outputs: tag-shortSHA1 which is much more convenient.Happy Git’ting :)- ferdy

  2. The problem seems to be I don’t know perl and I’m unable to change the perl script reliably :/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.