07.09.09
Lessons Learned from ID3 Tags
I regularly not only do sound for live events but spend a great deal of time and thought on managing a lot of The Master’s College’s digital audio/video assets. Along with my boss, this includes thinking through capture and acquisition, managing our computer systems, overseeing post-production on our audio messages and the authoring of a lot of our DVD’s, all the way to trying to implement backup strategies.
Recently we’ve been working on filling in the gaps and completing our archives of chapel messages on MP3’s and, even more challenging, standardizing the way the files are labeled and organized through the use of ID3 tags. I’ve been re-learning some lessons along the way.
1) Research and planning are key (and that means write it down). It is very important to do research and planning and to write those notes down. Research programs, prices, strategies. Find strengths, weaknesses, selling-points, and non-starters. For example: the first thing I should have was research what exactly ID3 tags are. You ask, what are ID3 tags. Well, they are attached to MP3’s and carry lots of helpful information including dates, titles, authors, etc. See here and here. Researching first is well worth it. For example: I spent a lot of time looking for fields to use because I didn’t understand the capabilities of the fields I already knew about. Also, I hadn’t written down the standards/conventions I was using for naming and grouping, etc. So, after a weekend or a long vacation it took some time to review and get back to it.
2) Testing is key. And the more refined the testing the better. The reason testing is key is simple: the research won’t tell you everything. I should have found out the following by testing, but instead I had to learn the hard way by running forward and then having to re-do lots of work. Did you know that: in iTunes only the “info” tab actually edits the ID3 Tag, the other tabs are only stored in the iTunes library. Also, I unexpectedly discovered that some programs (including a batch audio editor we use) will clear/delete ID3 Tag fields that they don’t recognize or deal with. So, some testing tips: test small parts of data first; test until you know both how to achieve the desired AND the undesirable results (then you will know what to avoid not just waht to do); test multiple products / methods even if you already have a favorite (you will often be surprised).
3) Knowing your goals is key. Is speed the most important or accuracy or both? Is use-ability and interface the most important or the exact feature set and greatest flexibility. The research and testing needs to be leading to an evaluation of how goals can be achieved. You might be saying don’t the goals come first. Well, yes and no. Often I don’t know what the benefits and down-sides in a certain product category might be until I do some of the basic foot-work. Advertisements and comparisons can help drive goals in a more refined but also diverse direction.
4) The right tool is key. The research and testing and goals need to lead to a conclusion on which tool (or combination of tools) will best achieve your goals. For example: I started using iTunes to edit the ID3 Tags for our MP3 library. But after doing the work I should have (researching, testing, and refining goals) I have ended up using a combination of our audio editing program and an specific ID3 Tag editor.
5) Finally documentation is key, and possibly even after the project is finished. Write down the procedures you decided on, save manuals and product documentation and manuals, save presets, backup files. This will save time for those who follow in your stead. And it is always good to think through the organizational continuity that will be needed when you leave your position for some reason.
Documentation might not just be for when you leave, but when you need to train others, because these lessons have lead to a successful, beneficial, and effective procedure.