Apparent Serious Bug in Beta 11

[alrobin]

I'm still having problems in Win Me, for both the 22050 Hz, 128 kbps option and the 44100 Hz, 96 kbps option. In both, the music is too early for the transition (worse in the first option). The other two that I had tested in beta 14 are OK.

[Igor]

Dear Al,

Thank you, I've received your mp3 file and time points.

So there is very interesting situation with this mp3 file!

Really it has length - 6:27.239 (as shown Nero Wave Editor after extracting into .wav file), but all players show 6:26.300 for this mp3.

(I've tested under WinXP and Win95 with exactly similar result)

There are two time points (and sound waves at these poins) at 6:00.000 and 6:01.000.

PTE v4.10 beta #15 after rewinding plays these waves on 900 ms. earlier each point (i.e. on 5:59.100 and 6:00.100 for second) as and v4.01 or v3.80.

But even WinAmp and Microsoft Media Player 9 after rewinding play these waves on 1 sec. earlier than they located in mp3 file! But all players play correctly extracted mp3 into wav file exactly as they are specified.

We've checked how it happened and found that this mp3 file has incorrect duration in the header. It lesser on 900 ms than in actual fact!

And of course, we can't make anything to fix it, because it's not our bug. Mp3 encoder incorrectly wrote length of this music file.

So please let me know what program and mp3 encoder you've used.

(I've tried to extract your mp3 file into .wav file and then recreated mp3 again with Lame mp3 encoder and this new mp3 plays OK after rewinding now.)

The problem with rewinding inside long mp3 file really was earlier before beta #15, but this new beta fully fix this problem. I even checked with 116 Mb mp3 file (44100, 16 bit, stereo, 256 kbps), 60 minutes. And I've created pulse/wave at 59:00 point and then converted my .wav file into this .mp3 (using Lame mp3 encoder) and beta #15 played this point exactly where it located as v4.01/3.80! But Earlier in beta #1-12 it was a delay in 500 ms.!

And beta #15 provides exact synchronization after rewinding.

[Guest guru]

Igor and Al,

please give a look here:

http://forums.syntrillium.com/topic.asp?TO...erms=fraunhofer

and here:

http://forums.syntrillium.com/topic.asp?TO...erms=fraunhofer

I never use CoolEdit to convert Wav into Mp3, but this seems an issue of Fraunhofer codec used by Syntrillium.

I never noticed it using Lame codec.

[alrobin]

Thanks, Igor - that clears up the mystery. It's one which has been confusing me for some time now (the truncation in one OS and addition of silence in another). So, I always thought it was something caused by the OS. By the way, in the new beta 15, in Win XP, I don't notice any of these problems.

I appreciate greatly your efforts on this problem which turned out not to be a PTE problem after all. (What other product support would give one this kind of attention?)

And Guido, thanks for the links. I have been visiting the Cool Edit forum some lately, but missed this one. There are so many experts on this forum, I learn something every day!!

[Guest guru]

Thanks, Igor...

I appreciate greatly your efforts on this problem which turned out not to be a PTE problem after all. (What other product support would give one this kind of attention?)

I totally agree, Al, and I too thank very much Igor for his admirable (in all meanings of this word) work for PTE and for us.

But let me thank you too, for all the work and the time you spent about this difficult problem.

[Igor]

Thank you all, and Al and Harold and Guido for your help in making of exact synchronization after rewinding!

[alrobin]

Just for the record, and info for anyone else plagued with the same problem, I have heard from Syntrillium (actually an Adobe quality engineer) re this problem, and he advised that with most mp3 editors the length of the mp3 file cannot be guaranteed so we should use only .wav files for accurate control over the synchronization.

He sent me a "fix" which pads the beginning of the file so that 44,100 Hz sampled files are no longer truncated. Now, in Win Me, my 22050 Hz files have an extra 0.027 sec added to the silence at the beginning, and 44100 Hz files have an extra 0.055 sec added, exactly twice the amount for the former.

However, (this is the interesting part), all files perform correctly in PTE, even in Win Me!

Anyone interested in this small "fix" file can contact Syntrillium support at support1@syntrillium.com .

And, by the way, the new "Audition" by Adobe will still use the Fraunhofer encoder.

[Igor]

Thanks, Al!

I only want to say my opinion, that I don't fully agree with Adobe Quality Engineer and I believe that correct MP3 should plays correctly.

CoolEdit writes fully correct body of MP3 file, but it only has incorrect value of duration in the header (4 bytes!). It's a mistake of CoolEdit.

[alrobin]

Thanks, Al!

I only want to say my opinion, that I don't fully agree with Adobe Quality Engineer and I believe that correct MP3 should plays correctly.

CoolEdit writes fully correct body of MP3 file, but it only has incorrect value of duration in the header (4 bytes!). It's a mistake of CoolEdit.

Igor,

I don't want to drag this out too much, but could you please tell me which bits would represent the "duration" bits (see this Description of an MP3 header file )? I don't quite understand what you are referring to - is it part of the 11 "frame sync" bits right at the beginning?