I’m required to log full details of everything I play, including annoying extra information like record label, publisher and CD reference numbers.
At the moment I’m using mAirList with an iTunes database - it’s working really well so thanks for such a great app - but getting all the logging details means adding them to the filename.
If the logging options included variables to pull information from any ID3 tag that would mean I could put all the info into the ID3 using iTunes and wouldn’t have to mess about with filenames (and then having to find them once they’ve been changed).
It’s probably timely to suggest that some of use use linear .wav files which do not have ID3 tags but nevetheless have cartchunk information imbedded in them ??.
We use Adobe Audition/Cool Edit pro to tag our wav files with the relevant information, and for additional information we use http://www.bsiusa.com/software/info_edit/info_editor.php as we have an association with several other radio stations with whom we share facilities.
It’s hard, of course, to find a standard which is acceptable across many automation platforms, but we find the BSI standard a good compromise, and their editor is freeware… handy for the budget conscious.
I suggest the above as mAirLit is fast becoming a significant player (pun intended) in the world of budget automation, thanks to Torben and the input of the forum contributors.
What do you think of this approach with .wav files, Torben?
I have already started work on the WAV/BWF metadata. Unfortunately, there is no third-party Delphi library available for that, so I have to scan and decode the file on my own. This makes things a little complicated. But it’s just a matter of time.
Regarding the original request: mAirList does not allow direct access to the ID3 data at the moment, but I can implement that.
Another possible solution is to use the User Defined Properties which can be edited in the Properties dialog (or through mAirListTag), and the %u{} logging. More information can be found here:
Thanks for that. The BWF support isn’t really critical for me, but logging data is
It looks like using user defined properties would work for me… However, given that I’m using iTunes to manage the music it would still be considerably easier if I could store the data I need within the ID3 tag in iTunes when I rip the CD into mp3 format, and then pull those fields out into a log file using mAirList.
If this isn’t a difficult thing to implement, then it would be great to have this facility at some point in the future, but it it’s a headache then I quite understand you not wanting to bother.
Having just had a play with user defined properties… yes it will work, but unfortunately it isn’t practical for what I need unless there’s a way to bulk edit UDP fields.
If I rip a cd into iTunes I can bulk edit most of the ID3 tags for information like composer, album title, artist and then put extra info in the comments tag.
If I use UDP in mAirList it looks like I’d have to do each track at a time, which would take too long to be practical
What I’m doing at the moment is ripping the CD into iTunes, then renaming the file to add the information I need, then getting iTunes to find the new file. That works, but if I could do it all in ID3 tags life would be good
I was a little hesitant to include new features into the current stable release 2.0, but the upcoming development branch 2.1 is still too far from release, so I decided to give it a try.
As of version 2.0.3, which I will upload tonight, you can access the ID3 data (but only ID3v2, not ID3v1!) with the %i{…} log variable, in the same way as the user defined properties are accessed with %u. You need to specify the four-letter frame ID as a parameter, which you can look up in this document: http://www.id3.org/id3v2.4.0-frames
For example, the song title has the ID “TIT2”, and thus can be accessed by “%i{TIT2}”.
A major problem was that ID3v2 frames can have different types: Simple text, numbers, string lists, etc. mAirList will be able to process most of these frame types (except binary data). If a type is not supported, you will see a “frame type not supported” error message in the log file.
3, NME: The Essential Bands 2006 [Disc 1], 0, 1/2, 1/20, The Killers, When You Were Young, Various
Which is great, but the comments field is a bit weird. The comments should contain the cd catalogue number but, as you can see just contains “0”. I get the same thing if i look at the details in windows explorer, but other ID3 tag readers give me the data I expect.
I’m presuming this is either a fault in implementation by iTunes, or the way mAirList and Windows read the ID3 tag.
Having looked a bit closer at the ID3 tags it looks like iTunes adds some custom tags including: COMMENT ITUNPGAP and a couple of others. These should probably be in the PRIV frame rather than the COMM frame, but there you go.
mAirList is definitely logging one of these other tags rather than the one I want. By messing about with the ID3 tag in an editor, if I re order these custom tags I can get mAirList to log something different from the COMM frame.
iTunes adds some custom tags including: COMMENT ITUNPGAP and a couple of others
Do you have a way to look at one of these files in a hex editor/viewer like XVI32? (Freeware, obtainable from [url]http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm#download[/url])
You should be able to see—just at the start of the file—the four-character internal tag names (TCON, TPE1, TALB, TRCK, etc.), each seven bytes before the value data for each tag: this may help, it may not.
Once you have the correct tag names (iTunes may be using ‘non-standard’ tags, or ‘misusing’ standard ones!), should be easy to log them using a string like (for example):%i{TALB}%tTrack %i{TRCK}
Just a hopefully helpful thought!
I have taken a closer look a the COMM frames. There can be more than one COMM frame per file. Each COMM frame has two values, “description” and “text”. Each COMM frame must have a different “description” value, and there is one main COMM frame, identified by an empty description field, containing the ordinary comment text displayed e.g. by Winamp.
The problem is that, so far, mAirList does only look at the first COMM frame inside the file. But this must not necessarily be the main COMM frame.
I have now made the following improvements which will be introduced in mAirList 2.0.4:
Upon loading an MP3 file, the main COMM frame will be identified and its text will be imported as the item’s comment.
%i{COMM} will return the main COMM frame.
You can access the other COMM frames by %i{COMM,description}, for example %i{COMM,iTunPGAP}.
I will release the new version shortly.
Torben
PS: Please note that both the frame name and the description are case-sensitive.
