Pacemaker str (beat analysis) files

This is where to post any information learned from hacking around with the Pacemaker
Post Reply
ubergeek

Pacemaker str (beat analysis) files

Post by ubergeek » Fri Nov 16, 2012 1:53 am

PMD str files

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;

...
}
NormalizeFactor is almost always 1. beatStartOffset is number of samples (eg. 44100 would be 1 second in a 44.1kHz track) until the first beat (used for auto-cue).

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.

poofygoof

Re: Pacemaker str (beat analysis) files

Post by poofygoof » Wed Nov 13, 2013 7:35 am

I've wondered how to design a systematic way to reverse engineer the format... while full source code would be lovely (and potentially allow the pacemaker immortality), I'm pragmatically OK with knowing how to care and feed the existing proprietary firmware with non-proprietary software.

it seems like a set of simple files (IE implulse ticks) with known BPMs could be used as a way to verify that the format has been correctly deciphered. has this been done?

has the zplane library been verified as the source of the realBeatLocations?

Sox
Admin Sox
Admin Sox
Posts: 347
Joined: Fri Sep 14, 2012 9:25 pm
Location: Bath, England
Contact:

Re: Pacemaker str (beat analysis) files

Post by Sox » Wed Nov 13, 2013 9:20 pm

No there has been no verification.


I think what you have to consider is, is it worth it this late in the Pacemakers development lifecycle. If we had full understanding of the str file format, what are you hoping that you or any of us developers would do with the knowledge?

Given the beat analysis most likely just gives the bpm (which I think can be edited via the editor or a 3rd party DB editor) and the information for the beat grid (which should not be required by any competent DJ that can use their ears for beat matching), I don't think it is worth the time and effort in trying to reverse engineer the file format. I believe I know enough to put new tracks without beat info onto a Pacemaker if I wished.

What would you do with the info?
Never experiment with drugs.... you might waste them

Sox
Admin Sox
Admin Sox
Posts: 347
Joined: Fri Sep 14, 2012 9:25 pm
Location: Bath, England
Contact:

Re: Pacemaker str (beat analysis) files

Post by Sox » Wed Nov 13, 2013 10:02 pm

Never experiment with drugs.... you might waste them

poofygoof

Re: Pacemaker str (beat analysis) files

Post by poofygoof » Tue Jan 21, 2014 5:29 am

zplane was nice enough to point me to some API documentation on auftakt, although apparently private licensing of the library is not something their legal department is set up to do. ;) 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...

sure, you don't need a beat grid to mix, and you can always time BPM "by hand" to get it in the database at least for sorting purposes, but it would be very handy to be able to manually touch-up beat grids by hand. for me, the holy grail would be to convert to /from ableton live so I could mix things that would be damn near unmixable by hand.

my hats off to the skilled DJs that can drop in beatless intros and have the downbeats perfectly match after 16+ bars -- that's not me.

and of course looking at the old forum posts I see this has been hashed over in the past, but it doesn't look like it has been definitively solved yet.

Sox
Admin Sox
Admin Sox
Posts: 347
Joined: Fri Sep 14, 2012 9:25 pm
Location: Bath, England
Contact:

Re: Pacemaker str (beat analysis) files

Post by Sox » Wed Jan 22, 2014 1:15 pm

To be honest if you don't solve it then I don't think it ever will as everyone elses interest has waned. Good luck
Never experiment with drugs.... you might waste them

Post Reply