Random m4a files not recognized

[Funklord]

A not so insignificant part of my collection is stored as m4a.
When trying to scan them with the PME, about 60% of the files are not recognized (they get a "!" next to the name)

Worth mentioning is that after Interleaving the files every 500ms these files do work on all car stereos, older mobile phones and portable players I've tried so far, with the exception of PME.

Any help is appreciated.

[Sox]

According the the user manual it supports
• MP3 (up to 320 kbps), M4A (AAC-LC), AIFF, FLAC, WAV, Ogg Vorbis and SND

The fact that they state "AAC-LC" after M4A makes me think there must be some other variant of M4A also available, which it does not support and my guess is that your files are that variation. Is there some correlation between ones you have purchases on iTunes and not?

If it doesn't play your files then there are no tweaks we can suggest, other than to convert your files to another format. There is most a likely a convertor you could find that will do it on a batch of files at ones, rather than you manually do it track by track

[Funklord]

Thanks for your help, but none of the files are from iTunes...
I'm still trying to analyze differences in the files, but the tools for m4a are pretty weak, and it seems to be for technical reasons.

The sound quality is already borderline horrid on these lossy files, and I don't think I could stand listening to them if they are re-encoded.
As it is, people have complained about the quality when I was playing a set :/

[Sox]

That's not good if your audience can hear it and are complaining. Generally I like to think the DJ (me) has a better ear than the audience for picking up on these things. What do they sound like if you play them on devices other than your Pacemaker, such as PC or mac? What bit rate are they recorded in?

I think some M4a files can be licence protected, maybe those from iTunes, which is why I asked this. I saw on the Traktor website that it too has issues with some m4a files.


If you like you can email me one of your files and I'll see what I make of it, and try it on my Pacemaker.


I think in future I would be avoiding this format. I can understand you not wanting to re-encode them, but if you have legal copies, I would not have thought it illegal to own copies in other formats obtained by "alternate means". How many files are you talking about?

[Funklord]

I started wondering whether or not this might be a bug to do with PME, and that maybe, the pacemaker itself isn't affected.
Then I again tried to delete files from PME and behold, the database seems to have become corrupt. I suspect that this may be a bug in the way it reads the file headers, since .m4a was a relatively unusual format at the time of making PME. Of course, I cannot be sure about this, and it's always the same files which are not recognised.

Anyhow, I use Linux, and the PME requirement has always annoyed me. I have no use for mixing or other features in it, and I've really only used it to put music on the PMD.
I found that there is an sqlite3 database on the device, and that it seems simple enough to edit in order to add music.

So right now I'm thinking of writing a small script or program to add music to PMD.
Basically something that can be run like ./add_to_pacemaker *.flac

I am aware of the issues for bpm, and that first beat and beat position are still very much a black box.

What I'm not going to do, is announce anything until the program does at least something useful.
So as not to disappoint with yet another dropped project.

At least, this way I could bypass PME, and see if there's even a chance of putting the files on PMD.

[Sox]

I've always thought the same about the editor, it only needed to be a means to get files onto the Pacemaker and never really understood the effort put in to make it a mix editor.

You should check out our developer section then. I've documented what I know about the database structure in their.
I also wrote an application PMExplorer which you can find on this forum, though it is for Windows and not Linux (though I am also a Linux programmer). It doesn't actually add files to the PMD, though that was on the roadmap (but without beat analysis), but the number of members/users did seem worthwhile the effort I was putting in. The number of Linux users would be even less, but that's up to you.

It really wouldn't be that hard to put files onto a PMD IMO. My apps can pull files off a PMD (such as one bought on ebay full of music), and restore the original filenames as they have hex filenames on the device.


Let me know if you need any help.

[Funklord]

I'm trying to figure out the true intent of the different fields in the database, because who knows, some future version of PMD may behave differently.
I saw that some of the metadata fields are duplicated as ind_* and that they have VARCHAR(32) set on them rather than VARCHAR(255), even though this is irrelevant for sqlite since it doesn't differ from TEXT, I'm assuming it's a hint that text should be truncated to 32 chars?
One thing that's missing in the sticky topic PMD database structure: track_flags has DEFAULT 0 in the db schema, but all files uploaded with PME get a value of 2, it would be nice to have some kind of idea what these flags might mean...
And the 2 different bpm fields have wildly differing values, and I know for a fact that neither was taken from file tags, so they must be generated by PME. Strange...

I need an identifier field. How is the global_id field calculated? and is it somehow related to the auto-generated filenames?

Since the libs I need (taglib, sqlite3) are best supported in C, I chose that... so there should be no issues supporting any other OS either.

[Sox]

you've hijacked your own thread and I think this is now better continued in the developer section.

However if you have a limited number of specific questions which you post in the developer section, I'm sure that I could get them answered by the original (and current) Pacemaker developer.


- My guess is that the ind_ fields limited to 32 chars may be the original ID3v1 tags whereas the non-ind_ fields may be the less limited user entered tags (those that you can modify within the editor)
- Please add corrections and additions to the DB structure thread so we can keep all the info in one place
- What do you need an identifier for - the tracks? I would use the unique track_id field where the next no. to use is the highest number used so far + 1 which in SQL would be "select max(track_id)+1 from tracks"
- I don't believe the GUID has anything to do with the hex filenames (the hex path and filename are related to "Jenkins One AT A Time Hash"