Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
RAW sizes differ between the original and the encoded-decoded files, headers appear to be same (44 bytes) size. - original wav - raw = header t4 14,276,68414,276,640 44 - encoded then decoded back (cbr and vbr) t4_b256_ms_h14,275,81614,275,772 44 t4_V1_b128_mj_q1_t 14,275,81614,275,772 44 The original .wav is reported to be 0:00.005 longer (1:20.933 vs. 1:20.928). The 1/200s difference might well account for the 868 extra bytes. Whether this is normal or accidental from the lame standpoint, I don't know. Liviu - Original Message - From: "Mark Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 02, 2000 10:15 PM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip True, it was the -t encode switch. By the way, isn't "lame -?" -t disable writing wav header when using --decode a bit misleading about this? Yes, that is a little misleading: "-t" option is listed twice, since it disables wav headers when decoding, and disables Xing headers when encoding. Thank you, Liviu P.S. The resulting .wav's are slightly _smaller_ than the original, see file listing below - t4.wav is the original wav, t4*.mp3 the encoded mp3's and t4*.wav the decoded wav's. Could easily be a bug in LAME. But before I look into this, can you do one more thing: compare the .wav headers? LAME writes a very spartin .wav header. t4.wav may include some extra "chunks" not in the LAME produced wav headers. 14,276,684t4.wav 2,590,511t4_b256_ms_h.mp3 1,862,685t4_V1_b128_mj_q1.mp3 1,862,268t4_V1_b128_mj_q1_t.mp3 14,275,816t4_b256_ms_h.wav 14,280,424t4_V1_b128_mj_q1.wav 14,275,816t4_V1_b128_mj_q1_t.wav There does seem to be a bug in lame 3.87 - the decoder no longer recognizes the VBR header, and instead encodes it as silence. This is why t4_V1_b128_mj_q1.wav is larger. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
The RAW's are different sizes, too: - original 14,276,640t4.raw - encoded then decoded back (cbr and vbr) 14,275,772t4_b256_ms_h.raw 14,275,772t4_V1_b128_mj_q1_t.raw The original .wav is reported to be 0:00.005 longer (1:20.933 vs. 1:20.928). I don't really mind the 1/200 second off - if that's the difference. Still, I thought I'd bring it up with you in case it's something you feel shouldn't happen. - Original Message - From: "David Balazic" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 03, 2000 9:49 AM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip Convert them to RAW format , thus stripping the headers away. David Liviu wrote: But before I look into this, can you do one more thing: compare the .wav headers? I'd be glad to, only I don't know much about .wav headers, even less about comparing them. One thing, though, doing a .wav compare in EAC reports the original .wav being 0:00:00.004 longer. Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
Some remarks about the ATHformula. The result are differing really a lot from my experiments. The difference is 10 dB and more at =12 kHz. For very young people the difference may be larger. Examples: Frequency Formula Experiment Difference [kHz] [dB] [dB][dB] 1 3.362.720.6 2 -0.25 -1.401.1 3 -4.56 -4.640.1 4 -3.38 -5.502.1 5 0.48 -2.272.8 6 2.083.89 -1.9 7 3.168.13 -5.0 8 4.78 11.27 -6.5 9 7.18 13.23 -6.0 10 10.57 14.39 -3.8 11 15.17 12.852.3 12 21.23 11.49 10 13 29.02 13.24 16 14 38.85 18.13 21 15 51.04 23.57 28 16 65.93 35.63 30 17 83.89 51.24 32 18 105.33 60.13 45 Binaural, Sennheiser HD 560, diffuse field. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
But before I look into this, can you do one more thing: compare the .wav headers? I'd be glad to, only I don't know much about .wav headers, even less about comparing them. One thing, though, doing a .wav compare in EAC reports the original .wav being 0:00:00.004 longer. Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
Convert them to RAW format , thus stripping the headers away. David Liviu wrote: But before I look into this, can you do one more thing: compare the .wav headers? I'd be glad to, only I don't know much about .wav headers, even less about comparing them. One thing, though, doing a .wav compare in EAC reports the original .wav being 0:00:00.004 longer. Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
I was only wondering about the size of the wav's (not the binary contents). As noted in a parallel reply from Mark, the discrepancy had something to do with the VBR header being decoded into extraneous samples. Thank you, Liviu - Original Message - From: "Zia Mazhar" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 01, 2000 11:37 AM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip Hello Liviu, Once you encoded the wave into MP3, the originality is lost forever. The first wave you'll get will have exactly the same quality of the MP3 of "CBR (-b256 -ms -h)" and the second wave will have exactly the same quality of "VBR (-V1 -b128 -mj -q1)". Think about it for some time, and it'll be clear to you why. - Zia Liviu wrote: Please pardon the question if naive but I couldn't find the answer elsewhere... I encode the same .wav to 2 different .mp3's - first one CBR (-b256 -ms -h), second one VBR (-V1 -b128 -mj -q1). Then I decode (--decode) the 2 .mp3's back, and the resulting .wav's have different sizes, both of them different from the original one. Is this expected behaviour? Best Regards, Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
True, it was the -t encode switch. By the way, isn't "lame -?" -t disable writing wav header when using --decode a bit misleading about this? Yes, that is a little misleading: "-t" option is listed twice, since it disables wav headers when decoding, and disables Xing headers when encoding. Thank you, Liviu P.S. The resulting .wav's are slightly _smaller_ than the original, see file listing below - t4.wav is the original wav, t4*.mp3 the encoded mp3's and t4*.wav the decoded wav's. Could easily be a bug in LAME. But before I look into this, can you do one more thing: compare the .wav headers? LAME writes a very spartin .wav header. t4.wav may include some extra "chunks" not in the LAME produced wav headers. 14,276,684t4.wav 2,590,511t4_b256_ms_h.mp3 1,862,685t4_V1_b128_mj_q1.mp3 1,862,268t4_V1_b128_mj_q1_t.mp3 14,275,816t4_b256_ms_h.wav 14,280,424t4_V1_b128_mj_q1.wav 14,275,816t4_V1_b128_mj_q1_t.wav There does seem to be a bug in lame 3.87 - the decoder no longer recognizes the VBR header, and instead encodes it as silence. This is why t4_V1_b128_mj_q1.wav is larger. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
