I'm using Mood, Preference and Tempo, but no way to take advantage of these in emplode. I would like to make playlists from these values.

A general ability to list and search other tag values would be nice (since, from the rejection of the art tag discussion, the data is obviously in there somewhere ;-)

I thought you could search on any field you liked in the Advanced box? Am I wrong?

Only those that were imported from the ID3v2 tags into the empeg's database. We try to keep the number as low as possible, because they take up memory on the empeg itself.

So you can't search on your own custom tags you've added to the *1 files yourself (through emptool or direct file manipulation)?

Yes, you can. What I mean is that we only transfer a limited subset of the tags from the ID3v2 header into the *1 file.

Ah, OK. I didn't realize Jloew was talking about ID3V2 tags, I thought he was already using emptool.

Jloew: You can search on whatever tags you want if you use emptool to fill them out.

so, how does a windows person do that? I guess not?

Can you point me to a quick primer on using emptool? ;-)

-Joe

I've never used it, but its a command line interface used by linux folks to load up the player with music. Unless you are into writing scripts, changing all that tag data one by one would take forever.

Keep in mind Roger's point that the more info you put in each tag, the faster you fill up ram space on the player. All the tags are crammed into a database by emplode and that database is stored in ram whenever the player is running. The remaining ram is used to cache audio data (among other things). I'm not sure how many songs it would take to fill up 16 MB, but it has been discussed before.

Sean

OK, point taken. However, the extra data of 3 ascii tags will be miniscule compared to the album art...

My next question is: why the heck would you cache the entire library of tags? I mean, I understand the performance issue for seeking on artist, genre, etc, but many of the tags are NOT used in the empeg player.

I can see a real problem with this because I've also used volume leveling with MM (stopped now that I have VolAdj), and that's consuming even more tag space. Sheesh, what if we start adding lyrics???

Roger, is this strictly true? If so, how hard would it be to exclude non-critical tag data?

This gets back to my request to filter imported tags anyway. If I could exclude these tags from import, then the cache size would be less of a problem.

-Joe

why the heck would you cache the entire library of tags? I mean, I understand the performance issue for seeking on artist, genre, etc, but many of the tags are NOT used in the empeg player.

Correct. Which is why (if I'm reading this thread correctly), the player only actually caches the data it uses.

You have to realize that when we use the word "tag" we are not necessarily referring strictly to ID3v1 and ID3v2 tags. We sometimes mean "The data in the player database that was extracted from the tag information at import time".

See, the player doesn't actually use the ID3 tags at all. Emplode just peeks at them to get its database data when you drop the files onto emplode. After that point, it only uses its internal database. So your MM volume leveling data is ignored by emplode and is not eating memory in the player.

OK, that's much better then. Thanks. But that does make me wonder why the large art tags are causing imports to fail. Why isn't it just ignoring them?

Maybe I don't understand the tag format. I would think there's a bit for tag type, a byte or two for a tag ID, then a pointer to the actual tag data. If this is how it works, then there shouldn't be any problem reading any tag and deciding to keep or ignore it. For the art data, the code seems to be trying to read the data and failing because it's too big. Why?

:-) no time for answers, just more questions!

Thanks for all your help on various threads, BTW - and your logo editor is handy.

But that does make me wonder why the large art tags are causing imports to fail. Why isn't it just ignoring them?

Because it was a bug.

More details:

- If your MP3 file starts up with a bunch of bitmap garbage that's something other than MP3 audio frames, how is the importer going to know that it's really an MP3 file? You certainly can't waste the importer's time on fully scanning every file out to the end. It's gotta give up and move on to the next file eventually. If it didn't, you could accidentally drop your Windows directory onto Emplode and be forced to reboot the computer as it tried to locate valid MP3 files.

- The only way it can accuratey determine the content of an art-tagged file is if the art tag is very small, or if the file starts with a valid MP3 header (allowing the scanner to skip on to the proper MP3 data).

So, there's still nothing it can do if you have both bad MP3 headers and a huge piece of art garbage at the beginning of the file. But they did fix one bug where even in some proper cases, it was still mis-detecting and rejecting the file.

To clarify:

MP3 files have ID3v2 headers. These consist of "frames". We import a limited subset of these, and transfer them into the *1 file, mapping them to our internal names (e.g. TALB is mapped to "source").

Thus, the album art _is_not_ included.

These *1 files are then compiled into the /empeg/var/database and /empeg/var/tags files on the player. If you add your own custom tags to the *1 file, (e.g. by using emptool), these extra tags will be compiled into the database file.

This database file is then loaded into memory on the car player. This is where the memory limitation comes in. This is why we only import a limited subset of the ID3v2 frames into the *1 file.

This _file_ is where emplode loads its data from -- it doesn't ever read the *1 files.

So, if you add MM volume levelling stuff to your MP3 files, we ignore it. If you add extra tags to the *1 files, we don't.

If your MP3 file starts up with a bunch of bitmap garbage that's something other than MP3 audio frames, how is the importer going to know that it's really an MP3 file?

Pardon me for saying, but that doesn't quite make sense. I haven't read the spec, but it would be silly if it said "look for this signature to find the music data". You'd have to have a hecka long signature to keep from accidently grabbing the wrong data.

Anyway, you reminded me of another problem we used to run into with tagged image files like TIFF. I bet it has more to do with the fact that the start of music data was at a fixed offset in early revisions of the specification. With the advent of "bitmap garbage" ;-) and tons of other tag data, someone got clever and put oversized header data (or perhaps just oversized tag data) at the end of the file, making some players break.

Again, I seriously doubt the code is "scanning" the file for valid data, but rather it doesn't know where to look for a relocated header or tag.

Sorry to be a pain - I've mostly just started deleting the art data. The music is more important!

I think he's saying that there appeared to be a bug in some taggers that didn't calculate or write the ID3v2 tag length correctly in the ID3v2 header, and it appeared as if it was just a bunch of garbage. The mp3 sync is 11bits long, but the ID3v2 spec specifies that data can be presented in such a way as to never match that sync, so as to comply with players that don't understand ID3v2.

OK, I think I understand - there is a "sync" signature?

The invalid tag length thing makes sense to some extent too.

Thanks all for bearing with me. I'll just wait and hope Roger and team figure it out. :-)

Pardon me for saying, but that doesn't quite make sense. I haven't read the spec, but it would be silly if it said "look for this signature to find the music data". You'd have to have a hecka long signature to keep from accidently grabbing the wrong data.

No, it's not like that. I'll try to explain again. Emplode only needs to look for a valid MP3 frame header (perhaps a few in a row) to verify that it's a valid MP3 file. The frame headers are not very big and they are easily recognizable. Hell, I'm doing it in slow-as-tar Visual Basic in my Gapkiller program and I can still rip through a 100-megabyte file in seconds, while reading and verifying every single frame header. (Part of the trick is using the last frame header data to decide where to begin looking for the next frame header.)

The reason Emplode goes to the trouble of verifying that the file is a valid MP3, is so that you don't try to import and play EXEs and DLLs as songs.

The problem occurs when the file does not START with valid MP3 frame headers. Such a file is, technically, completely out of spec and should in theory be ignored by Emplode. But Emplode gives it the benefit of the doubt and says "Okay, I'll look through the file a little bit, and if I don't see a valid MP3 frame header within the first couple hundred K, then I'll give up and assume it's garbage". It does this as a speed optimization.

So, if a file is out of spec (it doesn't start with a valid MP3 frame header), and also its art data is more than a couple hundred K, then emplode has no choice but to give up on the file and assume you're trying to feed it pictures of your dog instead of proper music files.

OK, got it. So, it's interesting that you have to search for a frame header rather than use a link list (you sort of suggest it in your comment "use the last frame header to decide where to look for the next").

I assume there's a good reason for that format.

What's wrong with my dog? ;-)

I assume there's a good reason for that format.

Don't ask me, ask Fraunhofer. I just work here, man.