Lame encoder and Sony MP3 CD

[digitalq]

Just got the new Sony MP3 CD Boombox, and am really enjoying it, however I've run into a snag making MP3 CDs for it.

Of course, I use DMC for all my ripping and conversion, and my encoder of choice is Lame. Apparently Lame is NOT the Sony's encoder of choice though. Any file encoded with Lame causes the unit to display "Not MP3" and move on to the next song. The boombox plays songs encoded with any other MP3 encoder I have tried (Blade and Mpeg Suite 2000) but no matter what combination of options I try, it refuses to recognize anything encoded with Lame. (have tried both 3.91 and 3.92)

Does anyone have any thoughts on this, or suggestions of things to try? I would much rather continue to use Lame for all of my encoding because of it's combination of quality, flexibility (low bitrates for audiobooks) and it's pretty fast. But I just can't seem to make it (the Sony) read anything using that codec.

Apologies for this being somewhat OT, but I figured there are some MP3 gurus in here who might be able to help.

:confused:
Chris

[digitalq]

Okay, I've successfully played files encoded with Lame 3.92 under CDex.

This tells me that the files produced by DMC must differ somehow.

I have noticed that DMC does not and will not use the lame_enc.dll in the Compression/Lame folder (or at least I suspect this, as I tried to upgrade to 3.92 this way and it still reported 3.91.

So now it's not an issue of giving up Lame, but rather one of finding out how and why the DMC files are different.

Of course I blame Sony for having an intolerant codec, but at the same time I think most anyone would be curious as to why this is happening. I know I am.

TIA for any help!

Chris

[Spoon]

It might be creating Id3v2 tags, have a look on dMCs Convfiguration page to set v1 only.

[digitalq]

That was one of the first things I did after reading the owners manual of the Sony.

Experimentation has revealed that the Sony does not dislike V2 tags, it just dosen't read them. I have gotten it to play files with V1 tag only, both V1/V2 tags, V2 only and no tags. In the last two cases it simply displays the filename without extension.

Can you recommend a good hex reader that will let me compare Lame encoded files from DMC and CDex in a side by side fashion?

Could there be some obscure switch that dMC is setting or not setting that makes the files produced different from CDex?

(Last question, promise!)
Is it possible to use dMC with the regged PowerPack to use Lame in CLI mode? That way I can try the regular .dll

Thanks for your help!

Chris

[digitalq]

Just have to figure out what to do with it...

I have found that the Sony does not like offset headers. The ones that will not play are created with the header offset at 417 (decimal) For some reason Lame is padding zeros for the first 416 bytes.

Hex editor I have won't let me remove them, so I can't absolutely verify this until I find one.

Next I need to figure out why Lame is offsetting the headers. It seems very odd that a compression algorythm would add bytes to a file seemingly without purpose.

It was very frustrating for a while there because I ripped some songs with CDex earlier today and they would not play. Of course for some reason the files I ripped yesterday with CDex would, so I was thinking dMC was the problem (I know, shame on me) :(

So anyway, who is MP3 guru enough to know why the headers get offset?

Chris

[digitalq]

That's it.

I got XVI32 and deleted the first 416 bytes of several of the MP3s that would not play before and now they play.

Now I just have to figure out why the offset.

I like it when I solve a mystery.

Chris

[digitalq]

Strangely enough, forcing Both v1 & v2 creation solves the problem. It looks like the Sony is pretty cool with an offset header as long as there aren't a bunch of zeros at the beginning of the file.

For now, I'll just satisfy myself with the presumption that the zeros at the beginning of the file are room left for ID3 formation etc.

So, the moral of the story is...

If you have a Sony MP3 CD player, always set v1 and v2 ID3 creation so you don't get headers offset by zeros.

As an alternative for files that you have already ripped, you can simply add a v2 header and that will put "ID3" as the first few bytes, even if you don't actually put anything in there.

Hey Spoon, don't you wish everyone solved thier own problems?

Chris

[Spoon]

Yes it is excellent

I have just converted a small wave file and the first frame of 0's is there also. Does anyone here know why lame would be writing a frame of 0's at the beginning? It could be just a 'feature' of the lame_enc.dll

[kriketini]

I found this forum while looking for solution of this same problem. Mp3 encoded in Nero 6 with Lame wouldn't play on my Sony boombox. It drove me crazy and I tried everything.

I found very easy and free tool you can use to repair Lame mp3 file. Here it is http://www.snapfiles.com/php/downloa...g=959079&loc=1


It removes all zeroes in front of first frame so Sony (and maybe other players) will recognize it as mp3 file.

[xoas]

Thank you for posting.
I would like to let potential users know that Kriketini's link is straight to the download site for snapfile and will automatically start a download. Cautious users might want to find out more about this program before downloading.

Best wishes,
Bill