Problem with Beta 6

[think(box)]

Yah, imagine this kind of access to gates....

OK Bob, it is indeed the rework of previous shows, or of the as yet unreleased shows finally being finished that motivates wanting it to work the same. But "more accurate" and "functionally correct" overrule any desire for "same as before". To be complete in this response, certainly a show already made always works the same, regardless of how PTE is changed after the show was made

[Igor]

Dear Harold,

I just tried, but I couldn't sense 50 ms. difference. You have absolute pitch, by the way! But I'm afraid to add this correction. Maybe it better if I add special function which you can call anytime and shift all transition points to the left or right on necessary value of milliseconds? This may help as in your case when highly-exactly synchronized show was created in previous versions of PTE and if some mp3 playback need be a little corrected in v4.10?

I suppose it can be a little difference (20-50ms.) in reference point in various music players when they start time reckoning. And it is NOT accumulating mistake. So shift may help, if creator see small difference.

And NO PROBLEM at all, if presentation is creating ALREADY in v4.10 with new music player. Because creator adjusts time points according playback of the new music player.

[alrobin]

Igor,

This feature would be quite useful. Can it be expanded to several "seconds" as well? It would also be useful when adding or deleting a few seconds of silence to the beginning of a show, for example.

[HaroldB]

Dear Harold,

But I'm afraid to add this correction.

Igor,

I take it that the reason you are afraid to add it is that somewhere along the line you found the 100ms to be an error, but the 50ms seems like it would be wrong to add? If not that, I'm not sure I understand why you are afraid to add it.

And NO PROBLEM at all, if presentation is creating ALREADY in v4.10 with new music player. Because creator adjusts time points according playback of the new music player.

Not really. This IS a problem, I think.

When I create a show, I find it hard to get the exact right transition points in PTE, since PTE does not display the waveform for the sound. So I have Cool Edit open at the same time, and I figure out the transitions by clicking in Cool Edit. Then I simply transcribe the transition times to PTE.

Unless I'm not thinking clearly (and it's early in the morning here ), that means that if PTE is 50ms off, the way I create PTE shows, I will always be 50ms off. No?

Maybe if you explain why you are afraid to add it, I can understand better.

Your idea of a an adjustment is fine by me, although I would expect it to be the least used option in the world ! OTOH, Al had already said that he likes it .

Harold

[alrobin]

Harold,

I see the global adjustment as useful, but only for the purpose of accommodating an insert of silence at the beginning of a show. It's not a high-priority requirement - I would only request it if Igor is going to add in a few milliseconds, anyway, to match up PTE versions. I think other features are more important.

I think I see where you are coming from now that you mention setting up the transitions using the waveform. I guess I don't get that precise with my transitions (witness my "Dempster Highway" show, soon to be released ).

I do my synchs using the timeline and "trial and error". I can see where you would want something more exact if you had a large number of cuts to sync. Rather than have Igor add 50 ms or subtract 50 ms, for new shows could you not add or subtract 50 ms to the time you see on the timeline? (assuming that the new PTE version timings match the timings set up in the previous versions, of course).

I realize this is not the optimum solution in your case, but it would be an out for Igor if he is reluctant to add the 50 ms.

I'm wondering, can this be a "granularity" problem? (i.e. a problem with how often PTE either queries the time, or receives an interrupt from the music timing, however it checks on whether a new transition is now required.)

[alrobin]

Just to add some more fuel to the fire, according to Cool Edit 2000, the music for my Dempster show starts at 1.7 seconds, but the first slide doesn't start until 3.1 seconds. I changed it to a "cut", and same thing - the time is off by about 1.4 seconds. So, the time for each cut would have to be "adjusted" by + 1.4 sec!

[Igor]

Harold,

Ok, please don't worry! I'll work until the problem not fully fixed.

Al,

Is the difference between timing in v4.01 and v4.10 beta #8 with this mp3 file?

p.s. thank you all very much! We'll continue work to make music player with excellent playback.

[alrobin]

No, Igor, this discrepancy between my CoolEdit and PTE is present in version 4.01, too. However, it is approx 100 ms different in value, as has already been pointed out by Sam and Harold.

In version 4.01 the music starts at 3.0 seconds into the show, and in version 4.10, beta8, it starts at around 3.1 seconds after the start of the show. However, my CoolEdit editor shows the music starting after only 1.711 seconds of silence.

This is along the same line as my experience with CoolEdit truncating my mp3 files, so the two phenomena may be related. I'll have to do some testing with .wav files too. I suspect they may react differently.

[alrobin]

Igor,

Here is something even more strange. I put the original .wav file in the show and the timing was off by about 100 ms. (just like going back to version 4.01). However, in Cool Edit, with this .wav file the whole 3 sec (2.945 to be exact) of silence shows up on the timeline without truncation.

When I save this file as .mp3, and load it back into CoolEdit again, I find the silence once again truncated to 1.7 sec. However, when I use this mp3 file in PTE 4.10 b8, the synchronization is correct. (i.e. the transition to the second slide - the first one which I am synching - matches the starting beat of the music, 3.100 sec along the timeline.)

This happens in both Win XP and Win 2000, on two different pc's.

[alrobin]

Igor,

It becomes even more strange! On my laptop (Win XP), when I load back my newly-created mp3 file, the silence truncates to 2.373 sec. (vs. the 1.711 sec. in W2K). However, the music starts at exactly 3.0 sec. in PTE 4.10. vs. 3.1 sec. in W2K.

In Win Me, however, there is no truncation from .wav to .mp3, and the music starts correctly at 3.0 sec. in PTE 4.10.

[cici]

Igor,

I don’t know if my test is useful, anyway here it is:

I made a test in beta 8 version with a MP3 prepared in Acoustica.

Sounds in this file begins after a silence of 0,5 sec.

In PTE, music begins exactly at 0,5 sec.

If I put a “cut” transition at 0,5 sec , picture is shown with a small delay (IPEG 640x480; 55Kb).

No problem if I put the “ cut “ at beat situated at 2”,700 sec: picture is open immediately.

[HaroldB]

No, Igor, this discrepancy between my CoolEdit and PTE is present in version 4.01, too. However, it is approx 100 ms different in value, as has already been pointed out by Sam and Harold.

Al,

That's not what I pointed out . I pointed out what seems to me to be about a 150ms (it's difficult to judge the exact amount) discrepancy between PTE 4.0 and PTE 4.10 beta 6. I see no discrepancy between Cool Edit and PTE 4.0.

The only "discrepancy" I have with Cool Edit has nothing to do with PTE. And that is that when saving an MP3 file (with the settings I give you in my post in that other thread), Cool Edit seems to add an undocumented .027 seconds of silence at the front of the file. That .027 seconds is visible if the saved MP3 file is closed and reopened in Cool Edit. And this is discussed as a given on the Cool Edit message board.

Harold

[alrobin]

Harold,

The 100 ms I was referring to is the difference between the discrepancies between CoolEdit vs PTE 4.01 and CoolEdit vs PTE 4.10. This would be equal, then, to the difference between PTE 4.01 and PTE 4.10. I couldn't remember exactly what difference which of you came up with, so that's why I said "approx 100 ms". I'm sorry I made it sound like it was a difference between CoolEdit and PTE. You made it very clear that you find no such difference (except for the .027 sec of silence) as you are using CoolEdit to spot the peaks in the music.

I know about the .027 sec of silence, but it only shows up for me in Win Me, unless using the parameters you referred to in the other thread solves the problem. I will make some more tests and let you know.

Thanks for your contributions in helping me track down this mystery.

[Igor]

Dear Harold,

We've worked for two days on this problem (100 ms' delay) and now I think that we've found real reason of this problem.

I suppose that new music player had really exact timing. And that 100 ms' correction is not necessary.

With this delay in my another test presentation, slides appear on 100 ms. earlier. Without correction all slides are showing exactly as in v4.01.

I've checked your mp3 file you've sent me and found that it has MP3 ID3 Tag (with info about this composition).

New music player plays wav, mp3 or mp3 with ID3 tag of same music composition with exactly similar timing.

The old v4.01 play wav and mp3 also as v4.01, but it shows incorrect timing for mp3 with ID3 tag! In the old player, current position during playing always more on 100-136 ms. It falsely calculates bytes of ID3 tag as frames with music and adds wrong additional 100-136 ms.

When I temporary removed ID3 tag (e.g. in WinAmp) from your mp3 file it also became play with delay of slides even in v4.01! Same result with converted wav file.

Please couldn't you also try with it? I suppose I've can made mistake in my testing after this long days of testings.

---

But you also said that you've composed time points in the CoolEdit? What exact version of CoolEdit you have got? Probably it also had similar mistake with ID3 tag? Please tell me what length it shows for that mp3 file? My copy of Nero WaveEditor shows 4 min., 8 sec. and 320 ms.

For example for second transition points (at 3,595 second in your presentation), Nero WaveEditor shows that it really placed in the middle of sound moment. But begining of this wave shoould be exactly on left on 100-136 ms.

So now beta #8 has incorrect timing with 100 ms. delay

But previous betas (e.g. beta #7) having correct timing.

But we will exact sure with after your testing!

Many thanks for your help!

[HaroldB]

Igor,

I see the problem .

First, let me give you the answers to your simple questions.

I am running CoolEdit 2000 1.1 build 2418. And the length of my MP3 file shows in CoolEdit as 4:08.320 whether I have an ID3 tag in it or not.

The transition point you picked to look at (at 0:03.595) DOES occur in the middle of the waveform. To make sure that my CoolEdit exactly matches your Nero WaveEditor, look at the waveform at 0:39.473. Is that EXACTLY where the waveform departs from silence in Nero WaveEditor? It's a very tiny departure in the left side of the soundtrack. That is followed by a trough at 0:39.480, which occurs in both the left and right side of the soundtrack.

I'm going to assume that CoolEdit matches Nero WaveEditor, and that they are both handling the ID3 tag correctly.

I did the same thing you did and used Winamp to delete the ID3 tag. Like you, I see differences in 4.0 timeline when I switch from the file with the ID3 tag to the file without the ID3 tag, and I see no differences in 4.10.

However, if I try to set the maximum time in the timeline in PTE 4.10, the maximum tine it lets me set is 4:08.355 in the file with ID3 tag and 4:08.219 in the file without the ID3 tag. In 4.00, it lets me go to 4:08.356 in the file with the ID3 tag and 4:08.220 in the file without the ID3 tag. Since we think the file length actually is only 4:08.320, I am assuming that you force the last transition point to be 100ms less than the end of the file, and the behavior in both 4.00 and 4.10 seems incorrect for files with ID3 tags.

The difference of 136 milliseconds in this timing is interesting, incidentally, because it "fits" with my perception that a shift of 100 was "not enough" to perfectly reproduce 4.00's behavior. IS the actual shift, in your opinion, actually 136ms?

So, based on what I see, I tentatively agree with your conclusion that in 4.00, using an MP3 file with an ID3 tag erroneously shifted 136ms, and that this did not occur with an MP3 file without an ID3 tag.

The question then arises how to deal with this going forward. If you fix the timeline behavior I described above, and take out the 100ms delay you introduced in 4.10 beta 8, then all PTE shows created before 4.10 with MP3 files with ID3 tags will shift 136 ms when recreated with PTE versions 4.10 and above. OTOH, if you leave the delay then all PTE shows created before 4.10 with MP3 files without ID3 tags will shift 100ms incorrectly.

So what to do?

I have three thoughts.

One is for 4.10 and subsequent releases to check the value of CreationTool in the PTE source file when a PTE file is opened. If the value is before 4.10 and the MP3 file has an ID3 tag, then offer the user a choice to automatically shift all transition points 136ms. Or perhaps don't even offer the choice -- just do it automatically. This may be more complicated than it sounds in case there are multiple MP3 files and some have ID3 tags and some don't. I use only one MP3 file per PTE presentation.

My other thought is for you to do what you suggested a few days ago, which is to simply add a new option to allow a music shift, and we can type it in manually if we have a show that really needs such precise timing.

The third option is, of course, to do nothing, except perhaps document it. And users who have such a demanding show and have MP3 files with ID3 tags can can adjust the appropriate transition points manually. I find that I have two shows that exhibit noticeable problems, the one I sent you and one other.

I prefer option 2, if that's not a significant amount of work for you, although option 1 would be even better.

I really DO think that you probably found the source of the problem, and I greatly appreciate your efforts to chase this down.

Harold

[Igor]

Yes, Nero WaveEditor shows exactly as CoolEdit.

Thanks for letting me know about results of your testing, too!

Now we're certainly know that v4.01 and earlier has 100-136 ms.' shift in timing on mp3 with ID3 tag and v4.10 has exact timing on any music files.

1) We've checked up in details calculation of timing in the new msuic player - no errors.

2) Also no mistakes in playing of frames in mp3 file. No one skipped.

3) My another presentation play exactly as v4.01 (without that 100 ms.' correction)

4) Old player (4.01) play wav and mp3 exactly similar, but it always increases on 100-136 ms.' current position if mp3 file has ID3 tag;

5) Old player starts playback as it were not from 0, but from -136 ms.! E.g. it shows that 236 ms. played after first 100 ms. of playback (mp3 with ID3 tag)!

6) Old player returns incorrect length (that mistake in calculation!). It shows 4:08.454, instead of 4:08.320. Here is that 136 ms. diffirence!

Beta #8 plays correctly mp3 with ID3 tag, it only shown incorrect length - also 4:08.455 ms. We've recently fixed this mistake. Now (future beta #9) it displays correct length - 320 ms. as CoolEdit or WaveEditor.

Of course, we'll add custom function to shift time-points.

And we'll think how to make auto correction for earlier created presentations.

Thanks again!

[HaroldB]

Igor,

I have just one minor question.

Do you think that the error in the previous versions is 136 ms, or 100 ms, or is it variable?

Harold

[Igor]

It depends on size of ID3v1 and ID3v2 tags.

So we'll calculate exact value of time difference for each mp3 file with ID3 tags.

p.s. I just posted new beta #9 with this fix.

Only one important note: after saving such project (created earlier in v4.01/3.80) in beta #9, it's not recommended to open it again in previous versions, because it will contain correction of timing for v4.10.

[HaroldB]

Igor,

Very good point about not opening a presentation in older releases once it has been saved in 4.10 if you are using MP3 files with ID3 tags. I would make sure to include that in the documentation for 4.10.

Harold