When you load music files onto your PMD through the PME, it goes through an "analysis" process. During this analysis, it looks at the beat structure of the music file and encodes this data into a proprietary file format called an "str" file. This file is used to do things like auto-cueing and auto-beat-matching.
The music file is renamed to a string of hex digits, and moved onto the PMD. The details are of the file and the location is loaded into the PMD sqlite database file.
Finally, the str file is renamed to have the same base filename as the music file, give the extension .str and then put in the same location as the music file.
The format of the str file is the only component which is not understood fully by the PMD community and is the only blocker to developing an opensource PME application.
It is possible to load a music file directly onto the PMD and update the sqlite db manually, but you will not be able to use auto-beat match or other PMD features that rely on using the beat structure.
str file structure
The str file is the output of a Boost serialization process. This encodes an arbitary C++ structure into an exportable xml file. The class (TrackAnalysedData) looks something like:
Code: Select all
Class TrackAnalysedData
{
public:
float normalizeFactor;
int beatStartOffset;
String realBeatLocations;
...
}
realBeatLocations is the output of a custom base64 encoding of a binary structure (as yet unknown). The base64 library is the "juce" library
http://www.rawmaterialsoftware.com/juce
I have written a wrapper to extract the realBeatLocations and decode the base64 string, though haven't had too much of a chance to analyse it. Let me know if you'd like me to post it here (it was on the old pmd forums).
In terms of the information in realBeatLocations, I'm pretty sure that the beat analysis is performed by a library called [aufTAKT] made by zplane software http://www.zplane.de/index.php?page=description-auftakt. The SDK documentation is here: http://www.zplane.de/index.php?page=sdk-docs.
If anyone has any further info, feel free to post here.
I posit that the base64(?) str representation in the database can be converted back to a binary representation with boost, and from there it probably isn't far off from what auftakt spits out. some test files should prove out the theory...