Clip+ freezes between songs (but only for some files)

Just got my Clip+ about a month ago.  It’s awesome.  I’ve noticed that certain MP3s seem to make the little guy freeze up before he will play them. Maybe 20 seconds or so of unresponsive UI, and then it continues on and plays the track like nothing happened.

SlotMusic cards work fine.  A number of other MP3s and oggs on the device play fine with no delay.  Could it be something funky in the ID3 tags?  The problematic tracks are all recent releases from MC Lars (truly genius awesome tracks, once they start playing, hehehe)…that’s the only point of commonality at this point.

Has anyone else seen this?

@kendricbeachey wrote:

Just got my Clip+ about a month ago.  It’s awesome.  I’ve noticed that certain MP3s seem to make the little guy freeze up before he will play them. Maybe 20 seconds or so of unresponsive UI, and then it continues on and plays the track like nothing happened.

 

SlotMusic cards work fine.  A number of other MP3s and oggs on the device play fine with no delay.   Could it be something funky in the ID3 tags?  The problematic tracks are all recent releases from MC Lars (truly genius awesome tracks, once they start playing, hehehe)…that’s the only point of commonality at this point.

 

It absolutely could be (and probably is) something in the ID3 tag. If you use a tag editor like MP3Tag, look at the Comments field. Some sources will load this up and that does indeed cause problems for the Clip+'s teeny brain to decypher. It just doesn’t know what to do with all this data. Delete (or <blank> out) anything in the Comments field.

Another cause? Humongous album art. If you have embedded art in the tag, you can check that also with MP3Tag. It’s senseless and stupid to have any album art over 300 x 300 pixel size. Come to think of it, if the Clip+ is the only player you have, it’s stupid to even have album art embedded in the file in the first place. It can’t display it.

@tapeworm wrote:

 

Another cause? Humongous album art. If you have embedded art in the tag, you can check that also with MP3Tag. It’s senseless and stupid to have any album art over 300 x 300 pixel size. Come to think of it, if the Clip+ is the only player you have, it’s stupid to even have album art embedded in the file in the first place. It can’t display it.

Not so.  A music collection isn’t only for one portable device.  A player bought in the future may be one that does display album art.  It isn’t worth the effort and time it takes to remove the album art for just one player unless it’s necessary to do so.

@mags1230 wrote:


@tapeworm wrote:

 

Another cause? Humongous album art. If you have embedded art in the tag, you can check that also with MP3Tag. It’s senseless and stupid to have any album art over 300 x 300 pixel size. Come to think of it, if the Clip+ is the only player you have, it’s stupid to even have album art embedded in the file in the first place. It can’t display it.


Not so.  A music collection isn’t only for one portable device.  A player bought in the future may be one that does display album art.  It isn’t worth the effort and time it takes to remove the album art for just one player unless it’s necessary to do so.

I have to agree with mags here…and I would add that doing your album art in a size bigger than 300x300 (500x500 is quite common) is actually future-proofing, because players are going to keep getting better screens. I have a player with a fabulous screen already…:stuck_out_tongue:

3.5 in (89 mm), 3:2 aspect ratio, 24-bit color depth, aluminosilicate glass-covered LED-backlit LCD, 960×640 px at 326 ppi

One can always easily add album art _ if and when _ it is necessary, like when a new player joins the family. Those larger images aren’t going anywhere. Google will always find them.

But if one’s only player is the Clip+ that doesn’t display any art in the first place, it doesn’t make sense to store huge image files that can choke the processor and slow down performance.

Just realized, I should have said in the first place, half of the problematic tracks are available for free here:

http://mclars.bandcamp.com/album/indie-rocket-science

…so feel free to download them and see if you can reproduce the situation on your own clip+.  (and rock out!  :-) )

I tried to download 1 or 2 tracks to see if there was anything weird with the tags, but it says “Service Unavailable”. I’ll try it again later.

Did you check them out with a tag editor as I suggested? What did you find?

I downloaded “Lord of the Fries”  at the link below  :smileyvery-happy: 

http://mclars.bandcamp.com/

I haven’t transfered it to my clip+ yet, but I did look at the tags and I saw a web address in the comments field and the album art is 700X700.  wow, that’s big!  Which mp3 format do you have?  The 320kbps or the VBR one?  It’s a nice touch that they offer several different formats including FLAC for free. 

@tapeworm wrote:

One can always easily add album art _ if and when _ it is necessary, like when a new player joins the family. Those larger images aren’t going anywhere. Google will always find them.

 

But if one’s only player is the Clip+ that doesn’t display any art in the first place, it doesn’t make sense to store huge image files that can choke the processor and slow down performance.

All my files with big art play fine on my Clip+, thanks to Rockbox!:stuck_out_tongue:

I will say that I always leave the comment field empty though. My friend’s Fuze takes half an hour to refresh and it’s mainly because he has practically a Wikipedia entry in the comment field.

I just took a look at the size of the album art that I downloaded from Amazon and eMusic (never bothered to before) and I see that many are 600X600.  I guess that’s become the norm.  So 700X700 shouldn’t cause a long lag in going from song to song. 

Marvin_Martian wrote:

 …would add that doing your album art in a size bigger than 300x300 (500x500 is quite common) is actually future-proofing, because players are going to keep getting better screens.

Agreed.

.