Apparent Serious Bug in Beta 11

[HaroldB]

Igor,

I'm not sure why I didn't see this before, but I think there is a bug in beta 11 of PTE that if you click on the timeline while music is playing, it doesn't always reposition the music correctly.

I simply can not figure out exactly when it doesn't work. I can not recreate it at the beginning of my show... it seems to happen only at about six minutes into it. The symptom is that when you click on the timeline, the blue arrow starts moving and the music continues playing where it was before. About a half a second later, the music seems to reposition, but by then it is obviously out of synch already.

It works perfectly if you hit Pause and then Play.

I hope that you can figure it out from my description, but if you need, I can send you the music and PTE files. The music file is an MP3, and is 8603KB in size.

Harold

[alrobin]

Harold,

I noticed something similar, in that around the 5-min mark, the synchronization seems to build up a delay of about 1 second in the re-positioning process. I am using mp3 as well, and testing with my Dempster show.

In other words, when you click back in time, the current music plays for about a second until the music at the new position "kicks-in", but from then on, everything is in perfect synch.

I assumed that this is just due to a processing-time delay, and found that if you reposition the cursor far enough back (at least 1 sec, but preferrably a couple of seconds) on the timeline, by the time it reaches the transition being tested, everything is back in sync.

Is this the same as what you are experiencing?

[alrobin]

Harold,

I just went back and re-tested my Dempster show under the new beta 12b, and you are right about it losing sync.

It seems to go off by about a second (the music comes in a second later than it should) around the two minute mark after I go back a few times by clicking on the timeline. You were right!

Igor, we definitely need a fix on this one!

[HaroldB]

when you click back in time, the current music plays for about a second until the music at the new position "kicks-in", but from then on, everything is in perfect synch

Al,

Precisely!

This was driving me crazy earlier today. I had a soft piece of music that I was doing fade transitions for, and I was sure that I was going nuts. Transition points that I was sure were good turned out not be good when I simply replayed them (by repositioning the blue arrow on the timeline)!

I finally STOPPED everything that I was doing, restarted all the programs, and carefully matched CoolEdit against the PTE timeline. And that's when I discovered this apparent problem!

OTOH, that's what beta testing is all about .

Thanks a lot for confirming this problem. When I realized that it didn't always happen, I figured that nobody would believe me .

Harold

[Guest guru]

Harold and Al, I don't remember what are your machines and your OS'.

This can be interesting for Igor.

[Igor]

I apologize for this unpleasant bug!

Thank you for informing about this.

Really rewind at the large mp3 file may takes some time, but synchronization have to be exact.

We're already working on it and hope to fix it as soon as possible.

[alrobin]

Guido,

I have the same problem in both Win Me (400 KHz Celeron) and Win 2000 (dual 400 MHz Celerons).

It shows up first around 2 min into the show.

When I click back on the timeline while the timeline is running (I've only tried it in AutoScroll Style 1 so far), the music becomes delayed by approx 1 sec. However, if I pause the timeline, click back to the same spot, and then start the timeline again, everything is back in sync. Then if I click back while running, the same delay occurs and does not catch up until I either pause or stop the show.

I don't seem to have the same problem in Win XP (700 MHz). However, in XP, I notice that the scrolling cursor backs up approx 0.2 sec periodically and continues on from there, so maybe this is its way of "catching up" in XP. (someone already complained some time ago about this phenomenon).

I don't use this method of synching much (maybe because I use mainly slow dissolves, and don't have occasion to get too accurate with my dissolves most of the time) so didn't notice this until Harold pointed it out. I usually pause and stop the show when adjusting the transition points.

[Igor]

We've found 3 reasons why the problem occurs. Two are fixed (including case with VBR mp3 file) and we're working to fix last reason. Now synchronization always will be very exact after rewinding.

The next beta will be ready today or tomorrow.

p.s. I'd like to very thank Harold for his fine attentiveness!

[JRR]

Igor:

Great !!!

But don't forget to get some sleep and eat some food every now and then !!!!

Doing great work !!

[Igor]

I've uploaded new beta #14 which should (I hope) solve that problem.

Thank you, Harold!

[alrobin]

Igor,

For me now it's worse than before.

Now the timeline goes out of sync in W XP too, by about 0.3 sec. Also, in all OS's (XP, Me & 2K) it goes out of sync when I press "pause" and then "start" again. (W XP used to just back up the moving cursor and continue on, without losing sync, but only when I clicked back on the timeline.) Now it happens both when I click on the timeline and when I press "Pause".

Hope this doesn't spoil your weekend! It can wait til Monday!!

[Igor]

Ok, not a problem!

By the way, is your mp3 VBR or with constant bitrate and what its duration?

Probably you've tested with old time points? Please try to make new mp3 and set points in wave editor. I tried several times with various formats and now it works exactly.

Anyway we have another variant of rewinding. New (fast, by the way) algorithm will use another way to calculate position in mp3 file.

[alrobin]

Igor,

CBR, 10:44.6. And 22050 Hz sampling rate.

I will create another mp3 and set sound bursts as you suggest, for a more accurate test.

[Igor]

Ok, thanks,

By the way, did you noticed that v4.10 has smoothed fade in/out of music (as WinAmp) when user call pause/stop or rewind?

Even newest Microsoft Media Player 9 (just I for the first time installed it) has short sound clicks when you do these actions (as and PTE v4.00 and earlier).

[alrobin]

Yes, the sound quality is great, even when stopping and starting! You've done a great job on the new sound player.

[Guest guru]

quote:

"the sound quality is great"

_________________________________

I agree. By the way, few days ago a French user, member of Fanaphot forum (Michel's French PTE forum) asked me if something had changed in 4.10 beta sound player, because music sounds now much better than in v4.0...

[alrobin]

Ok, Igor, here is the result from my latest test, with Win XP.

This time I saved the original wav file to .mp3 based on 44100 Hz sampling, 128 kbps CBR The test music selection has 3 short bursts of tone (20 ms) at 1-sec intervals, every minute, starting at 2 min.

I still detect a slight delay (about 0.2 sec) in the music, this time only when clicking back on the timeline as before for Win 2k, and not until about the 9-minute mark. However, it does seem to clear up when I press "pause", reposition the cursor, and then continue again. I've checked the tones against Cool Edit to ensure they are at the exact positions in PTE.

I'll do a similar test for W 98 and 2K, and also for the 22050 Hz sampling rate again this weekend.

Are you having similar results with the new beta, Harold?

[alrobin]

Igor,

I have made some tests of Beta 14 on my Win Me setup, using an mp3 file, CDR of 96 kbps, & 22050 Hz sampling rate. The results are as follows:

As I have earlier indicated, the mp3 file length varies between Cool Edit and PTE; saving as an mp3 with the above parameters cuts off some of the silence at the beginning when viewed back in Cool Edit. However, in PTE, it plays close to the original .wav file timing. ?????

Pressing "pause" and clicking back on the timeline now both cause a delay in the music. This delay increases over time on the timeline.

For example, at 2 minutes, "pause" causes a delay of approx 0.2 sec., and "click" back on the timeline causes a delay of approx 0.4 sec. There is also a slight discontinuity in the sound when one presses "pause", repositions the cursor back a few seconds, and then presses "play" again. The cursor also momentarily backs up a slight amount. These discontinuities do not occur when one clicks back on the timeline.

At 10 minutes, this delay increases to approx. 0.9 sec for "pause" and 1.1 sec for "click".

I will continue to make more tests, particularly using 44100 Hz and 128 kbps on the W Me system, and 22050 hz in W XP for comparison with the first two tests.

Let me know if you have any other ideas.

[alrobin]

Results for Win Me, with mp3: CDR, 128 kbps, 44100 Hz: similar to those for Win XP.

Even at 2 min. (no difference for either pausing or clicking back.)

6 min:

- Pause: no delay

- click back: approx 0.1 sec delay

10 min:

- Pause: no delay

- click back: approx 0.2 sec delay

Again, there is a discontinuity in the music when one pauses, clicks back in time on the timeline, and re-starts the playback. The cursor backs up momentarily and there is a slight glitch in the music.

Conclusion so far: it makes a big difference if you convert to mp3 using 22050 Hz sampling & CDR 96 kbps. Will do some tests to see if mp3's at 96kbps react differently than those at 128 kbps or whether the delay is caused by the sampling rate alone.

[alrobin]

Test results for Win 2K were very interesting!

With mp3, CBR 96 kbps, 22050 Hz:

- 2 min: Pause: music 0.2 sec delay; Click: 0.4 sec delay (it's always 0.2 sec later than for pause).

- 6 min: Pause: music 0.5 sec delay; Click: 0.7 sec. delay

- 10 min: Pause: 1 sec delay; Click: 1.2 sec. delay

With mp3, CBR 128 kbps, 22050 Hz:

- 2 min: Pause: music early by 0.3 sec; Click: 0.1 sec early .

- 6 min: Pause: music 0.9 sec early; Click: 0.7 sec early.

- 10 min: Pause: 1.4 sec early; Click: 1.2 sec. early.

With mp3, CBR 96 kbps, 44100 Hz:

- 2 min: Pause: music early by 0.3 sec; Click: 0.1 sec early .

- 6 min: Pause: music 0.6 sec early; Click: 0.4 sec early.

- 10 min: Pause: 1.0 sec early; Click: 0.8 sec. early.

With mp3, CBR 128 kbps, 44100 Hz: (almost same as for128 kbps, 22050 hz)

- 2 min: Pause: music early by 0.3 sec; Click: 0.1 sec early .

- 6 min: Pause: music 0.8 sec early; Click: 0.6 sec early.

- 10 min: Pause: 1.4 sec early; Click: 1.2 sec. early.

Go figure!

[Igor]

Thank you, Al for such detailed results of your testing!

Please try new beta #15

p.s. you can verify correctness of position in .mp3 with .wav file of that .mp3 file in PTE. Because there is no such difficulties with position in .wav file.

[alrobin]

Igor,

Based on a quick check of my worst-case scenario, the new beta works perfectly! Thank-you so much! (you must have worked all night??? )

Edit:

Woops! All is fine in W 2K for the 22050, 96kpbs scenario. However, both the 22050, 128kbps and the 44100, 128 kbps scenario still have the same problem - sound bursts coming too early. (as much as 1.4 sec at the 10-minute mark.) However, playing through without pausing or clicking on the timeline sounds just right.

[Igor]

I had full sleep

Just we've discussed yesterday new algorithm and today we've wrote this new rewinding.

Please can you send me to igor@wnsoft.com this 128 kbps with 22050Khz mp3 file (in ZIP archive, up to 7-10 Mb)? We'll check it up to find exact reason of difference. Also please let me know exact position of that 10-min.' time point.

p.s. by the way, how this 10-min. mp3 file works in v4.01?

[alrobin]

Igor,

It acts up the same way in version 4.01, using Win 2K.

I will send you the file - the two 10-min pulses are at exactly 10:00.0 and 10:01.0 (you can't miss them). The mp3 file is 10:45.802 in length.

The pulses were positioned at exactly those times in the .wav file, but in the .mp3 version they occur at 9:58.776 and 9:59.776 due to clipping at the front of the wave. However, on the timeline, they still play back at the 10 minute mark if no pause and replay is selected.

[alrobin]

Igor,

I tested beta version 15 in Win XP, and it seems to work as intended in all 4 scenarios! That's great!

Now if MS would stick to the same parameters in all OS's, there would be a lot less work for all of us!