I noticed that in 2.0b7, it considers any MP3 with album art stored in it to be an "invalid MP3 file". Almost my whole collection has album art in it, so until this gets fixed, I will be using 1.02 which plays them no problem. I created these files with Music Match Jukebox and if I clear the album art out of a file, it will play fine on 2.0b7.

Good, clean, concise bug report, thanks. I have posted this to the internal bug list.

Centipedex, could you email a file exhibiting the problem to [email protected] ?

ta,
Peter

Just a note - at first I thought this was the whole problem, but it appears a bit trickier - SOME album art causes this problem.

It looks like MM 7 does not cause this problem when using album art. I have two albums created in MM6.x with album art that do not import, but a third created in MM7 that imports fine with album art.

Great catch, tho! I was struggling with this one until you figured it out!

-Joe

The other thing which might be causing problems is that Musicmatch VBR headers are completely undocumented. We can't read them.

Hmm. I copied most of my CD's to computer using MM6.1 so that would verify what you said about MM6.X album art not working right. I could try loading the new software back on and trying to play something I ripped with MM7... I don't know if I feel like doing that all again though as I might end up having to reload my entire library again if I go back to 1.02.

None of my MP3's are VBR though. I use constant bit rate 128kbps/sec on all my files.

Same here.

OK, so it looks like it's probably down to album art, then.

Take it from someone that works at MUSICMATCH (me...and svferris), the problem is the album art. A more exact description would be that tagging files with album art causes the ID3 tag to reach a size limit that the Emplode software doesn't like. I'm not sure why it would work with MMJB7 and not 6.x though.

[edit]P.S. Thanks for using MUSICMATCH!!

Is the album art included in the length of the ID3v2 header? If not, that could be the problem. We only go looking for MP3 data up to 192Kb distant from the end of the tags.

If the problem might be with the Album Art, try using Zlurp! mp3 encoding front end to create an MP3 with the album art in it. It uses properly readable MP3 headers. This will narrow it down to an album art problem, or a header problem.

Yes, I was just about to speculate it might be size-related because SOME album art fails, and some succeeds. It was probably a coincidence that it worked in MM7 and not 6.

-Joe

try using Zlurp... It uses properly readable MP3 headers

As opposed to what? Really, if the headers are bogus, emplode must at some point make a judgment call between "this is a valid MP3 with a 2Mb JPEG unnecessarily stuck on the front" and "come off it mate, this is a JPEG not an MP3".

Currently this heuristic is set to 192Kb.

Peter

it considers any MP3 with album art stored in it to be an "invalid MP3 file"

Whoops, there was a bug, whereby album art bigger than 192K confused it. FITNR.

Peter

I was just about to remove all my album art :-( and had a thought that might prove a useful general solution.

First, make the default list of imported tags limited to those used in the soup views - why bother even trying to bring over those you don't use?

For those who require custom tags for custom apps, add two flags: include and exclude. You could then explicitly include/exclude whatever tags you want. Maybe for include, you can have an "all" parameter that essentially does what is default today.

Hmmm?

-Joe

hmmm.. I don't know how big my album art is, but they are not big in pixel size... I'd be surprised if they were anywhere near that big (192k) and they don't work

I'm not sure I understand your suggestion. To clarify:

1. emplode does nothing to the MP3 file when it's sent to the player.
2. We look for Xing headers to figure out average bitrate, etc.
3. We only extract the tags we care about to our DB.

hmmm.. I don't know how big my album art is, but they are not big in pixel size... I'd be surprised if they were anywhere near that big (192k) and they don't work

The one in the example file you sent me was 360K. Or at least, there was 360K's worth of ID3v2 tag at the beginning; I was assuming that almost all of that was album art. Does ID3v2 base-64 encode its binary fields, or something daft like that?

Peter

There are a couple of binary encoding schemes used by ID3v2. One is ``synchsafe'' integers, which use 8-bit bytes to hold 7 bits of data with the MSB set to 0. Another is ``unsynchronization'', which states that if you have two adjacent bytes that look like 11111111 111xxxxx, then to change it to 11111111 00000000 111xxxxx. You also have to change any 0xff 0x00 byte combinations to 0xff 0x00 0x00 to prevent a decoder from seeing those two bytes as the first two-thirds of an unsynched 2 bytes.

Synchsafe integers are mandated in certain sections, mostly headers. Unsynchronization is not ever required, but is suggested when you aren't sure that the tag will always be read by an ID3v2-compliant mp3 decoder, and is turned on by a flag in the main header to indicate unsync for all frames, or in individual frame headers. Both schemes are intended to prevent a decoder from seeing an accidental MPEG sync header within the ID3v2 tag.

Neither one should account for a two-fold increase in size.

I've looked at the file, and it's got a kosher windows bitmap fixed to the front in an 'APIC' frame, followed by a huge swathe of zero bytes (240,000 bytes of them), then the rest of the ID3v2 header.

The only thing that I can think might do this is some kind of broken exponential space allocation scheme.

Sounds like a broken padding implementation. ID3v2 can have padding at the end of the tag to make it easier to edit. The padding is supposed to be all 0x00, but is not supposed to exist between frames. But, then, ~240kB of padding seems a little outrageous, too. The fact that the APIC is a WinBMP doesn't inspire confidence, though.

Wow I clicked remove tag and it shrunk by about 300k.. that seems a little excessive for the album art which is only 200x200 pixels.. anyway I still wish the Rio Car could handle it.

Wow I clicked remove tag and it shrunk by about 300k.. that seems a little excessive for the album art which is only 200x200 pixels.

Yes, it is excessive. The problem is (as mentioned elsewhere) that the album art is in an awful format. It was Windows BMP, which is almost always much bigger than it needs to be. Then, there seems to be some kind of a padding bug where the ID3v2 tag is wasting gobs of space on empty bytes.

I have a question...Did you tag the file with the art using the MMJB "Paste art from clipboard" function in the tagging dialog? That might explain the BMP format depending on where you got the art from. Try taking the same file and tagging it with a nice small JPG from a file...not the clipboard. See if that passes Emplode's check.

P.S. If you want, you can just remove the album art from your entire MP3 library using the tagging dialog. It'll take a while if you have lots of files, but it will work. That is what I did. I think I had about 150 tracks that wouldn't import originally, so I just selected the whole library, went to Edit Tag, then removed the art. No biggie, and everything imported just fine after that.

I'm not saying that you're wrong about the clipboard reason for the WinBMP, but if that's the case, it should be reported to the MM people as a bug. Just doing a copy-n-paste from the clipboard is remarkably lazy. It should do a transparent conversion to PNG before putting it in the tag. I say PNG because that way you don't lose any data. JPEG would probably be the more appropriate format, but given that a JPEG encoder should ask the user for compression variables before converting, it wouldn't be as transparent. (PNG and JPEG are specifically referenced in the ID3v2 standard, by the way, as the most appropriate image encodings.)

Ok, I removed the album art from one of my files and it shrunk by 300k, then I added the same graphics, only this time from a JPG file and it only grew by 7k, so it looks like this is more of a MM glitch. I am going to redo my library that way so I should be all set.

Try taking the same file and tagging it with a nice small JPG from a file...not the clipboard. See if that passes Emplode's check.

I'll just mention again that Emplode's checking had a bug in 2.0 beta 7, and that in the next release even whaling great AVIs of album art will be correctly skipped if they had valid ID3v2 headers (like centipedex's BMPs did).

Peter

The reason why I mentioned the Windows Clipboard is becuase I have noticed that when I do screen captures using Alt-Print Screen, it always captures as a BMP. I was wondering if he got the art using a similar method. The copy the paste from clipboard feature in MMJB will paste whatever the original src you copied was. So if you copy a jpg o the clipboard and use that....you get a jpg file in your tags. I think that one of the problems is that many people get the art from the "Media Window" while using the Now Playing feature. If you copy the image from the Guide page, you will get a JPG (as all the album art images are), but copying from the media window is part of the windows app, and I have a feeling that Windows is doing something stuipd when it saves the image to the clipboard.