And a couple of questions

[renowden]

1. When you normalise and/or channel balance, does it take the peaks after track boundaries and corrections have been applied or before - the answer will determine whether I ought to removed the big glitches at start and end (due to turntable switching) before processing?

2. It may be only imagination but if I remove a large section using cut and splice, it seems all my track boundaries shift. Is that the case, if so I should do the final track boundaries after all other cleaning up?

[Derek]

1. When you normalise and/or channel balance, does it take the peaks after track boundaries and corrections have been applied or before - the answer will determine whether I ought to removed the big glitches at start and end (due to turntable switching) before processing?

Yes normalisation (and channel balance) measures peaks of the corrected wave and ignores all parts of the wave before, after and between tracks. Therefore you should normalise as the last action before saving.

2. It may be only imagination but if I remove a large section using cut and splice, it seems all my track boundaries shift. Is that the case, if so I should do the final track boundaries after all other cleaning up.

No your track boundaries shouldn't shift unless they are very close to a cut point. In this case they can shift because you cannot have a track boundary within a cross-fade region. If you find your boundaries are shifting, get back to me and I'll investigate further.

all the best

[renowden]

Thanks - I will look at point 2 more closely if I suspect anything. It was only a feeling and may have been because I didn't set them very accurately the first time around.

[renowden]

I have investigated this more closely and this is what I have discovered.

I knew I had a particularly difficult album to process, so what I did was to very carefully mark the beginning of each track using the resolution on it's finest 0.1 second and setting the boundary within one tick mark of the first note (0.02 second), a bit tighter than I would normally do.

I then manually went through the entire album removing the glitches. There were quite a lot of bad ones as I suspected and many I had to remove using cut and splice. Fortunately the rhythm was generally quite slow and it didn't affect it noticeably. There were 67 in all over an album of 43 minutes and 13 tracks. No cut was very large, usually 50 to 100 frames caused by bad clicks and stylus bounces.

Then when I looked at the track markers again, track 13 start was some distance from where it should have been - nearly 0.6 second BEFORE the start of the music and getting progressively less for the earlier tracks. I can't tell if the end markers also moved

So the movement of the track marker forward when sound data is being removed suggests that it is not that the compensation is being neglected but rather that it is being a little over done on each occasion.

I have saved the files in this state, though being 480MB, they would be difficult to send. I hope that I have provided sufficient information to enable you to reproduce the problem.

[Derek]

Yes, thanks for this report.

From your description, I now understand what is going on. The problem occurs because track boundaries in Wave Corrector are constrained to be at multiples of 588 samples. (This is so tracks are always an exact number of audio CD frames). Therefore when you use cut and splice to remove a few samples, all the track boundaries after the cut are adjusted to maintain the 588 sample requirement. In practice, this means that boundary position will be 'rounded down' to the next 588 multiple position. (Note, 588 samples represents one seventy fifth of a second.)

If, as you have done, you make multiple cuts in a file, then each one will result in a rounding down operation. And therefore, you'll get an accumulation of these rounding down errors - which is what you're reporting.

Unfortunately, it would be quite difficult to amend the code to avoid this. So I think the best advice is to make all your cuts before setting your track boundaries.

I'm sorry that my previous answer did not explain this. Imust have forgotten about this aspect of the code.

all the best and thanks again

[renowden]

Thanks - I'm glad is was easy to explain. No problem at all adjusting them afterwards, I was just worried that something might be going awry.

[Glenn]

Derek wrote:

Yes normalisation (and channel balance) measures peaks of the corrected wave and ignores all parts of the wave before, after and between tracks. Therefore you should normalise as the last action before saving.

In the case where cuts were made prior to normalizing it might be necessary to recheck the cuts. I've noticed that the normalizer doesn't work in the spliced areas, leading to drop-outs.

Glenn

[renowden]

Now that is not something that I had noticed. I will be interested in What Derek has to say about that.

[Derek]

Yes, well spotted!

I've been investigating this and, as reported, normalisation is not applied to the cross-fade region of a cut. I'll have to fix this in the next release. There should be a beta out within a week or two.

Thanks for the report.