Clip Zip turning off on its own, can turn it back on by connecting it to PC

I bought my first Clip Zip ever less than a month ago and love it. However, on 2 different occasions I've been unable to turn it back on normally. I've only been able to revive it by connecting it to my PC.

I'm not sure if this explanation applies to my case, but I learned on this thread that what *might* be going on is that the firmware crashes when trying to read the metadata on the tracks.

The second time it happened I was able to witness it. The player appeared to experience problems to play one track in particular--and the glitch caused the pause button not to work for some reason--and soon after it turned itself off. The player was at least 80%-85% charged when that happened.

But, like I said, connecting it to the PC revived it. Annoying, but I could learn to live with it.

Two questions for the Clip Zip veterans out there:

How serious is this issue? Is it "normal"?

Is there any way to turn it back on without having to connect it to my PC?

First make sure there's no problems with the file structure of the drive and that you're using the latest firmware. Make sure your files are well encoded or at least properly repaired. foobar2000, Mp3Val and AudioTester can do that.

I use MP3Tag or foobar2000 to remove all the extraneous information the Clip doesn't use. It doesn't read Composer so there's no need for a Composer tag, right? When you save any changes that rewrites the tags properly.

Using those simple steps I haven't seen a freeze up in years. It was time consuming the first time but I make sure to follow the same testing procedures for all my new files then tag them properly and have trouble free playback.

Thanks for all the comments and links. I'll put them into practice ASAP

I originally was apprehensive to get any MP3 player because of the "horror stories" I've read in some places, namely how short-lived they seemed to be. Watching my nephew's brand new Creative Zen die in less than a month, or a friend's iPod start behaving erratically in 1 or 2 months, reinforced that impression.

Heh, I even spent a few months reading about Sansa's players before I got the "courage" to buy one. I know that spending $50+ casually on electronic "toys" is a trifle to some, but not for me. So I didn't take the step until I felt I was well informed about the product.

I'm please with it, but those freezes began to awaken those irrational fears again.

All in all, I feel inclined to agree with all of you that the issue was the file, and not the hardware. I've started using MP3Tag a week ago to do the simple chore of adding tags to tracks... maybe I've been adding unnecessary tags :-P

Sansa should add a comprehensive guide in the Clip's manual about how to properly tag tracks for the Clip Zip so it doesn't choke on them... so I don't have to bother you people with such basic questions :-P

Ah, but unfortunately, it is normal with the Clips, if there are incompatible file formats present, or problematic tags. As you note, the solution is to avoid both of those situations, scrupulously. I, likewise, have never had a freezing issue, likely because I generally only have mp3 files and keep my tags simpler and "clean."

All in all, I feel inclined to agree with all of you that the issue was the file, and not the hardware. I've started using MP3Tag a week ago to do the simple chore of adding tags to tracks... maybe I've been adding unnecessary tags :-P

Sansa should add a comprehensive guide in the Clip's manual about how to properly tag tracks for the Clip Zip so it doesn't choke on them... so I don't have to bother you people with such basic questions :-P

Again, thanks for the help

Here's a reference for you....some MP3Tag settings. Look at what is in the options box in the image below....

And the tags I fill....
All the other areas, like comments, etc., leave open.

Marvin pointed out something that I think is very important above that some people may miss and I'll get back to that in a minute. While none of my clips have ever frozen other than when RB was in beta for the original V1 clip, my e260 would occasionally freeze until I started removing all the ID3v1 tags from all my files. While I can not confirm this to be a fact on the clip, I can say that since I began that practice I've never had the e260 or any of the 6 clips we have freeze.

Thanks for the additional info, Marvin and WalkGood. I've made the suggested changes within MP3Tag. I don't mind to fix all the tracks if that means minimizing potential playback problems later on Besides, using MP3Tag is kind of fun.

BTW, the screenshots were awesome, Marvin. Thanks.

Out of curiosity (on the MP3Tag "options" graphic above): is there a reason to use ISO instead of UTF on the tags?

Last edited by hierogrammate; 06-24-2012 at 05:40 AM.
Reason: typos, and forgot to give thanks :-P

Make sure your files are well encoded or at least properly repaired. foobar2000, Mp3Val and AudioTester can do that.

Hmm, I used foobar2000's file integrity verifier as you suggested on the audiobook I ripped from my CD, and it said "Decoded with minor problems: Reported Length is Inaccurate." Can I overlook that (I have no idea if that's the kind of error that could make the Clip choke on it), or should I use "Fix VBR MP3 header" to remove it?

I experimented with a few tracks and "Fix VBR MP3 header" did the trick... however I read elsewhere that even though foobar2000 might no longer detect the error, "Fix VBR MP3 header" might cause other programs to detect errors... so I'm not sure if I should go ahead with all the tracks.

Anyway, if it happens that you're not sure either, I'll simply experiment with it and hope the Clip doesn't explode.

Thanks for the additional info, Marvin and WalkGood. I've made the suggested changes within MP3Tag. I don't mind to fix all the tracks if that means minimizing potential playback problems later on Besides, using MP3Tag is kind of fun.

BTW, the screenshots were awesome, Marvin. Thanks.

Out of curiosity (on the MP3Tag "options" graphic above): is there a reason to use ISO instead of UTF on the tags?

Yes....it's most compatible with the Sansa players' firmware.

Quote:

Originally Posted by hierogrammate

Hmm, I used foobar2000's file integrity verifier as you suggested on the audiobook I ripped from my CD, and it said "Decoded with minor problems: Reported Length is Inaccurate." Can I overlook that (I have no idea if that's the kind of error that could make the Clip choke on it), or should I use "Fix VBR MP3 header" to remove it?

I always use "fix" to correct the error, then re-run the integrity verifier to be sure it's fixed. On the very rare occasion that something is still amiss, then I click "rebuild mp3 stream" and that will finish the job.

Quote:

Originally Posted by hierogrammate

I experimented with a few tracks and "Fix VBR MP3 header" did the trick... however I read elsewhere that even though foobar2000 might no longer detect the error, "Fix VBR MP3 header" might cause other programs to detect errors... so I'm not sure if I should go ahead with all the tracks.

Anyway, if it happens that you're not sure either, I'll simply experiment with it and hope the Clip doesn't explode.

I've never had an issue with other programs or devices detecting any errors after using these foobar utilities.

In fact, even though I don't ever use the Sansa original firmware anymore, I've stayed with these tagging practices, and they've worked on everything I've tried them on.

Not knowing what other software may be affected I can't make a comment on that. I do know that using foobar2000's file integrity verifier hasn't caused a problem on any of the multiple software and players I've used mp3 files with after processing. You may want to ask the poster on HA what problems they've encountered.

My primary concern when I went to straighten out my collection was making sure the resulting files worked reliably in all the situations I used them. I used foobar2000 to spot the files with multiple tags and MPEG stream corruption and fixed those. The ones with stream corruption or too high peaks were usually so bad they had to be replaced.

I still had occasional lock ups so I ran all 3 of the foobar2000 file integrity utilities in sequence trying to fix the last of the problems. That got me about 99.7% fixed. I ran MP3Val and it found more issues foobar2000 doesn't identify. I had MP3Val fix those and haven't seen a problem since.

I still run MP3Val and foobar2000 over any mp3 files I get now. Those that are well encoded by LAME always test clean. Those ripped using FhG like Windows Media Player report usually inaccurate file lengths. I just use foobar2000 to "fix" them and they play with no problems on my portable players.

Fixing the inaccurate reported file lengths is quite possibly a voodoo step that isn't needed. My experience has been it doesn't hurt and hasn't caused a problem so I go with it as part of my routine in introducing new content into my library. YMMV.

Fixing the inaccurate reported file lengths is quite possibly a voodoo step that isn't needed. My experience has been it doesn't hurt and hasn't caused a problem so I go with it as part of my routine in introducing new content into my library. YMMV.

Ok then. I don't mind the extra voodoo step. Thanks for sharing all that info in your post.

Hmm, you said you "ran MP3Val and it found more issues foobar2000 doesn't identify." Apart from editing tags and the options, I didn't notice MP3Val could be used to actively search for certain problems. My fault since, apart from the basic chores, I haven't explored the program thoroughly yet. I'll give it a hard look later today to see all the other stuff I haven't used.

I've been reading ABI ever since I began to "rebelliously" search for non-Apple MP3 players. It's a pleasant surprise that it's forums are also a priceless source of info.

I don't think MP3Val can be used to actively search for problems. I just drop the files in and let it fix whatever it identifies. I had a mp3 files encoded by at least a half dozen different mp3 encoders that wrote the frames a variety of ways. Some did it properly and others hadn't. The ones that did it wrong would sometimes cause problems.

I haven't had MP3Val find a problem in a VBR file I've encoded using LAME in at least 3 years. MP3 files ripped with WMP will give the inaccurate length error in foobar2000 but MP3Val passes them as not having any problems. Using foobar2000 I fixed the few of those I had and they play without error. They probably were fine as they were, I just fixed them for the sake of uniformity.

I still MP3Val it to check files I get from free, legal online sources. I find that some of them may have problems with how they were written. It's possible for them to sound great but have been written with some encoder that didn't do a great job writing the frames. Running the foobar2000/MP3Val combo works to have them play on my portables without problems.

I always rewrite the tags. I've found any number of combinations in some albums I've downloaded. Checking the details and rewriting them brings everything to the same standard. I figure if everything is uniform there's less chance of confusing the software or hardware on the portable player and causing a freeze.

I always rewrite the tags. I've found any number of combinations in some albums I've downloaded. Checking the details and rewriting them brings everything to the same standard. I figure if everything is uniform there's less chance of confusing the software or hardware on the portable player and causing a freeze.