It is on purpose that the INFO tag is also written on cbr files. This is
not
a bug.
Could you explain the purpose? It's not immediately apparent to those of
us not well versed in the inner workings of the MP3 encoding process.
This tag stores some information about encoding parameters,
Hi Steve,
The problem was that the initial VBR tag (all zero's) was inserted into
the
MP3 file for CBR files, so when the beWriteVbrTag function was not called
at
the end of the encoding process you end up with an empty frame at the
beginning of the MP3 file.
It is on purpose that the INFO
Gabriel Bouvigne wrote:
Hi Steve,
The problem was that the initial VBR tag (all zero's) was inserted into
the
MP3 file for CBR files, so when the beWriteVbrTag function was not called
at
the end of the encoding process you end up with an empty frame at the
beginning of the MP3 file.
-
From: Steve Lhomme [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 14 July 2002 ?. 11:16 PM
Subject: Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP
Boombox
Albert Faber wrote:
This is indeed a bug in Lame 3.92, the problem has been fixed quite a
while
ago in the CVS
]
Sent: 12 July 2002 ?. 8:33 AM
Subject: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
After several tests, I've found that encoding an mp3 with LAME 3.92 will
make it unreadable in the Sony ZS-X3CP Boombox mp3 player. 3.88 worked just
fine. Normalization, Stereo, 192, etc. Doesn't
Chris Holt wrote:
--- Steve Lhomme [EMAIL PROTECTED] wrote:
Actually it's a bug of the application using the LAME DLL. At the end of
the encoding the application should ask LAME for the VBR frame and write
it at the start of the file. Just switch to a good LAME DLL user app :)
I'm still
Chris Holt wrote:
Dear nirv:
Had this problem too and found (with a hex reader) that 3.92 puts a
frame filled with zeros at the start of an MP3. The sony does not like
this and assumes the file is something other than an MP3 when it sees
the leading zeros. If you put an ID3 v2 tag
--- Steve Lhomme [EMAIL PROTECTED] wrote:
Actually it's a bug of the application using the LAME DLL. At the end of
the encoding the application should ask LAME for the VBR frame and write
it at the start of the file. Just switch to a good LAME DLL user app :)
I'm still confused as to why this
Dear nirv:
Had this problem too and found (with a hex reader) that 3.92 puts a frame
filled with zeros at the start of an MP3. The sony does not like this and
assumes the file is something other than an MP3 when it sees the leading
zeros. If you put an ID3 v2 tag onto the file (using Lame or
