Using another playout system (DPS), I’m able to write ID3 tags containing Artist, Title, Intro, Outro, End, Year, Category, Opener details etc. I can also export to a fixed-field or CSV output file (TXT).
Would mAirList be able to handle this at some point ?
The other option I have, is a VB application that grabs the DPS ID3 tags and writes to a .bcx file (yet another playout system!), but in the rather useful INI file format:
[code][MARKERS]
Start Point=410
Intro=24530
Out Point=187896
These .bcx files exist alongside the audio, and are named as per the audio file, ie: Big Audio Dynamite - E=mc2.bcx
I suppose another option would be if Torben allowed MDB Access Database support, the date from the CSV could be imported and then mAirList can be told what data appears in which columns… Torben, if you would like a sample MP3 file to extra the DPS ID3 data - I’ll post one here for you.
Using another playout system (DPS), I'm able to write ID3 tags containing Artist, Title, Intro, Outro, End, Year, Category, Opener details etc. I can also export to a fixed-field or CSV output file (TXT). Would mAirList be able to handle this at some point ?
Charlie: All mAirList Properties data is stored as an XML document inside an [b]TXXX[/b] ID3 V2.3 tag (user-defined text tag) inside the MP3 file.
Alternatively… all MLP files are XML documents internally, and store much (?all) of that data as well. So as a last resort, bung your tagged MP3 files into a Playlist (or probably Playlists), Save the Playlist as an MLP, and then tinker with its internal XML at will (I recommend Microsoft’s XML Notepad if you can still find somewhere to download it from!).
This tag has a Description of mAirList and the text data is typically 300–400 bytes in length, including XML tags.
The only low-cost/no-cost ‘MP3 tag wrangler’ program I’ve found which can detect, display, and extract these tags is Magnus Bråding’s Mp3-Tag Studio, if that helps?
I can read the tags in VB no problem - it’s the bulk processing of them that I’m not too good at! I’ll have a look at that tagging program, and maybe even the XML stuff.
...in VB no problem - it's the bulk processing of them that I'm not too good at!
[code]Dim objFSO As New FileSystemObject
Dim objFolders As Folders
Dim objFolder as Folder
Dim objFile as File
Dim strText as String
Set objFolders = objFSO.GetFolder("C:").SubFolders
For Each objFolder In objFolders
For Each objFile In objFolder
strText = objFile.Name
…
Next
Next[/code]
Does that help? It may not be 100% but it’s off the top of my head.
NOTE that you do need the VBScript run-time (SCRRUN.DLL) installed to make the above objects accessible.
maybe even the XML stuff.
ISTR there are some good tutorial documents about XML wrangling [i]via[/i] code on the MSDN site; if not, then a swift [i]Google[/i] for [b]VB +"XML document"[/b] should find you rakes of sample code.
--
BFN
CAD
We establish a new file type, say “.mmd” as in “mAirList meta data”, which contains a single “FilePlaylistItem” XML block as known from the .mlp playlists. The .mmd file is placed along with the audio file, like this:
D:\musik\Some Artist - Some Title.mp3 (Audio)
D:\musik\Some Artist - Some Title.mp3.mmd (meta data)
When opening an audio file, mAirList looks for the .mmd file and reads its contents. The data should have precedence over the values found in the file tags. I can also establish a new “Save (.mmd)” button in the Properties and Extra PFL dialogs.
I see the following benefits:
Its easier to import data from other systems, as you do not have to mess around with the file tags.
You do not need to alter the audio files in any way.
It works with any file type, also .wav, .ogg etc.
You can save the meta data while the file is opened in a player, which does not work with file tags.
The .mmd files can easily be deleted when you stop using mAirList, which of course won’t happen
The meta data file sounds like a good move. It sounds like it’d be just as quick to retrieve that data as it would the ID3 header. Gets my vote.
Whilst I like the ID3 tag info - I’m not convinced that it’s the place to store complex stuff like In/Out points and Broadcast-critical detail. I think a database or .mmd file is the better option.
Obviously use of MMDs would be optional, but if we went that way, we’d be talking about (in our case) potentially an extra 20,000 little MMD files. I would start to worry about the performance of the file system directories as such (especially across a network), given the sudden doubling of the number of entries per directory.
(Note: No, we don’t store all our MP3s in one directory!)
I do however see the benefits and agree the points both Charlie and Torben have made, plus of course ‘off-site’ tagging of tracks would be just as easy (perhaps easier?) using MMDs. This point matters to us as we are about to ‘weed out’ our music library and both a) remove/repair any ‘faulty’ tracks; b) remove or at least mark up tracks with profanities; and c) add mAirList cue points. We plan to distribute that work among several reasonably trustworthy people, so using MMDs would mean ‘return’ of data by e-mail becomes a practical option.
So yes, overall I agree it’s a good idea to have optional metadata files, and vote in favour.
PS: MMD is already used by a couple of graphics programs. Can I suggest MBD (mAirList Broadcast Data) instead? I would have suggested MPD (mAirList Playout Data) but that is used by MS Project as a database file extension.
all MLP files are XML documents internally, and store much (?all) of that data as well. So as a last resort, bung your tagged MP3 files into a Playlist (or probably Playlists), Save the Playlist as an MLP, and then tinker with its internal XML at will (I recommend Microsoft’s 
