Re: Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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, encoder delay, It allows you to know some parameters used for encoding, and could allow a totally gapless playback with proper use by the decoding software The problem is that this tag as to be written after encoding, so when encoding is finished the programmer has to call a specific function. Unfortunately it seems that the dll internal doc was not updated, and so so programmers didn't called this finishing function. In order to understand a few of the advantages, you could try using Encspot on a such a file. Then select Lame tag on the right click menu... Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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 tag is also written on cbr files. This is not a bug. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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. It is on purpose that the INFO tag is also written on cbr files. This is not a bug. BTW, in LAME there is the possibility of not using the INFO/XING frame. That's what I used in the ACM (as it doesn't make sens in that case). But it's hard coded (a boolean or something like that). ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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. Albert - Original Message - 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 repository. In addition, I patched lame_enc.dll v3.92 and is included in the latest CDex version (version 1.50b5). Albert What was the bug ? ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
This is indeed a bug in Lame 3.92, the problem has been fixed quite a while ago in the CVS repository. In addition, I patched lame_enc.dll v3.92 and is included in the latest CDex version (version 1.50b5). Albert - Original Message - From: nirv [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 matter. The only thing that made it readable was changing to 3.88. If this is not known, perhaps there can be a fix or something? nirv ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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 confused as to why this frame is written into a CBR file. Well. It's a Xing frame for VBR. An info frame when it's a CBR file... But it's there. And if you are implying that dbPowerAmp is a bad LAME DLL user app, I would have to respectfully disagree. :) Seems like :) ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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 onto the file (using Lame or anything else) this will be solved as the Sony will then search through the file until it finds the MP3 header. The ID3 v2 data is written into this area instead of the zeros. ZS-X3CP can only use ID3 v1 info, but it does not mind v2 info being in the file BTW. There is also a switch that will turn this off, (writing of the vbr data area, I think) but I forget what it was. If you want to try that, you could look in the docs for Lame, or the archives of this mailing list (if they exist?) , as someone here told me a while back. 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 :) ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
--- 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 frame is written into a CBR file. And if you are implying that dbPowerAmp is a bad LAME DLL user app, I would have to respectfully disagree. :) Chris ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
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 anything else) this will be solved as the Sony will then search through the file until it finds the MP3 header. The ID3 v2 data is written into this area instead of the zeros. ZS-X3CP can only use ID3 v1 info, but it does not mind v2 info being in the file BTW. There is also a switch that will turn this off, (writing of the vbr data area, I think) but I forget what it was. If you want to try that, you could look in the docs for Lame, or the archives of this mailing list (if they exist?) , as someone here told me a while back. Chris At2002-07-12,01:33:00you wrote: 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 matter. The only thing that made it readable was changing to 3.88. If this is not known, perhaps there can be a fix or something? nirv = = = = = = = = = = = = = = = = = = = = = = Best regards. Chris
