The last couple of days I put 30GB of MP3 on my player (M2a) and set a lot of Wendy flags. When I started using the player again I noticed there are a lot of "hicks"' in the files (about every 10 seconds or so, irregular). It sounds like I am using bad rips. However,
- the files where fine before (also on the Empeg) and play fine on my computer
-all files are affected on the Empeg
-it only seems to be in the left channel (I noticed when looking at the VU meter visual, and it also sounds like that)

When I hook up Hyperterminal I get an error message (I think) that says:

! mp3_decoder.cpp :1049:Failed to find valid sync after seeking to offset 3190
959, error=0xc0044000

I did it again a lot of times and now I get the same, only a different offset each time:
! mp3_decoder.cpp :1049:Failed to find valid sync after seeking to offset 1021
548, error=0xc0044000


I am using 2b13 and Hijack 302. I flashed both again with new, good files, but that did not help. Also Hijack 299 does not make a difference. I also did a hardware test (with cntr-T) in Hyperterminal, but the tests show the hardware is fine. The empeg with the same software before I did all the uploading worked fine (already contained most of the files before the re-build, the main difference are the Wendy flags)

So, what is wrong? Is my hardware broken, a bug in the software, or did I do something wrong?

Please help me since I am getting very nervous.

To be clear, do you get the ``failed to find valid sync'' message continually, or do you get it just once when the player starts. If the latter, then that's a known ``bug'' that's not really a bug. It's just the player being a little too verbose. I think that there's a FAQ on it. If, however, you're getting it more than once to constantly, then there's something wrong in regards to that.

I get it once when the player starts. It is at the end of the start-up log. So, if it is a known bug, there is something else wrong. May be something has gone wrong when I synced the 30 GB?

Without hearing it, it almost sounds like it's hiccuping when it accesses the drive. Is it a new drive? Have you ever gotten a drive not found error on boot?

Let's be absolutely clear on this:

The "Failed to find valid synch" message is a NORMAL status message and does not indicate a problem. EVERYONE gets that message, and no one else has the skips you describe. So the message has nothing to do with the skips.

Now, let's get on with diagnosing the actual problem, which is the skips.

- Does it happen both at home and in the car?

- Is your EQ set flat (there were some one-channel bugs in the EQ) ?

- Do you get any other error messages besides the one we've already determined is unrelated?

I did some very extensive testing and found the reason for the hick-ups:
All my VBR files are corrupted for some reason. F**k! In a major way. And my f****ng backup is also ruined.

Thanks for the responses, sorry to have bothered you. I am going to drink a lot of beer and wonder whether I should recollect and rerip 20 GB of files.

All my VBR files are corrupted for some reason.

Define "corrupted"?

Do they pass a cursory scan from MP3Trim? Is it just bad VBR headers that can be corrected with MP3 Tag Studio?

As tfabris says all may not be lost. That said, your difficulties illustrate why I ended up using CBR with a larger bitrate, instead of VBR. Too much pain. Disk is cheap.

Corrupted means 10+ missing frameheaders per file, as reported by MP3Trim and other programs. As far as I know this means rerip since it can not be fixed. Too bad .

If you know a good trick please let me know. It will save me weeks of redoing everything.

I thought you had said these files worked before though, in which case I would be very worried about how they had become corrupted.

Corrupted means 10+ missing frameheaders per file, as reported by MP3Trim and other programs.

Yup, that's corrupted all right.

Were they that way BEFORE you put them onto the player? If so, it's an SEP and I hope you can find out what caused it.

The following happened:
-The player was working fine, but I still had to upload 5GB and do the Wendy tags
-So I thought, hey do a complete rebuild offline, so I can check for doubles, run some VBR error checking etc.
-I used my backup for that since I still had the Empeg as backup in case something went seriously wrong.
-I checked and everything seemed fine since it is very hard to hear the anomalies on a lowfi system like a PC
-So, after 4 days of labeling etc. I made a backup-backup, deleted everything on the Empeg, and uploaded everything again

So, what went wrong:
-The VBR checking was too obtrusive, all VBR files are corrupted (thanks to MP3 Tag Studio). I know for sure since I added 20 files in the end after the VBR checking and they are the only one's still ok
-I should have made a copy of the Empeg before + after VBR checking + uploading. Still 4 days of work lost, but what the hack
-Check the quality not only on a PC but also on a good system like the Empeg
-Think before you do. I am really mad I was so stupid

And to make things worse, I convinced my girlfriend to buy a 2 DIN car finally (check the For Sale forum for some details). So, I did not have to sell the Empeg anymore . This totally stupid "file management" sets me back at least a couple of weeks, if not months, don't know whether I am willing to do that.

I'm sure the author of MP3 Tag Studio would like to see a copy of one of the files that was trashed by its VBR header fixes. Were you running the latest version?

(He's got a user account on this BBS, by the way, if you'd like, I could direct him to this thread.)

That is a good idea. Please redirect him directly to me. I do not have his name, otherwise I will do it myself.

He has about 5000 files to choose from, so some improvement should be possible. I am running a new version, may be not the latest since I did not check lately (2 months old or so).

BTW, I opted for completely rebuilding my collection. It will take some time, but whatever. So, my Empeg is not on the market anymore .

Ok, here I am...
(thanks Tony and Douglas for bringing this thread to my attention)

This all sounds very strange to me. The VBR-header repair function does not touch the sound data at all, and an invalid VBR-header could never have that effect either.

The only thing I could think of that could potentially cause a similar problem is that you mistakenly chose the CR/LF fix repair type instead of the VBR header repair type, and in spite of all the warning messages processed your non-damaged mp3 files with it?

But if you have a sample file which is ok, but that will get corrupted in this way when processed with the VBR-header repair function of Mp3/TS, I will be more than happy to take a look at it for you.

/Magnus

Hey, that sounds likely. A CR/LF fix would have the same result, I'd bet.

If that were the case, I'm guessing there's nothing he can do since the CR/LF fix removes bytes, and there's no way to get the file back the way it was after that. Am I right?

Yes, in that case they would be very hard to repair, that is correct (and that's also why there are very clear warnings in the program about not running this type of repair process on non-damaged files).

I think it was the CR/LF stuff. And indeed I was so stupid to ignore the warnings.

However, it may also be related to the Mass set tags/flags -> MP3 flags to set -> Whole file option. This option caused a lot of [censored] when I tried to use it. It corrupted some files straightforward and hang my system a couple of times. Are there any known issues with this option? If I am the only one having issues with this option it might be my system + the CR/LF thing.

Setting the flags in the whole file could be potentially dangerous if the frames are already out of sync in some way, since wrong data then can be recognized as a frame header, and edited. :-(
It is not recommended to set the flags in the whole files if you don't really need this (e.g. if a program refuses to play/share files which has the copyright flag set in any frame or so).

There is a clear warning message in the program about this too (showing up when you attempt to set the flags in whole files in the mass set tool), but in some earlier versions of Mp3/TS there were less warnings about it though.