Page 1 of 1

"Lost" end-of-track boundaries

PostPosted: Fri Sep 02, 2011 4:09 pm
by bmbguy
I've seen this problem before, but now I think I've finally figured out how to make it happen.

Testing the new beta 1, but I believe the problem existed in prior versions.

Every now and then, I would find that my track boundaries would get 'lost'. In other words, as I was trying to use the toolbar button to go to 'next track boundary', I would find that the program would no longer stop at the end boundary of some tracks and instead go right to the beginning of the next track. And I would look in the corrections list, and I would see "Start of Track 3" followed by "Start of Track 3", instead of "End of Track 2" and "Start of Track 3". I never knew how I got in that situation, and I couldn't get out of it unless I rescanned for tracks -- which was a real pain because I already had my gaps and fades set the way I wanted.

Well, I think I've finally figured out how to duplicate the problem.

I am working near the end of a track, with the 'track end' and next 'track beginning' markers set quite close together. I then select a portion of the waveform at the end of the current track and a bit of the beginning of the next track, thus INCLUDING THOSE TWO TRACK MARKERS in the selection area. Then I right-click on the selected area, and 're-scan' that area for corrections (I often re-scan the very end of the track at level 5 to get most of the noise out). When the re-scan is done, the end marker of that first track still looks like it's there, but it's really 'gone'. The corrections list now says "start of track x' twice, indicating where the next track starts, but the end of the track I was working on is now gone. And if I use the toolbar to move to 'next' and 'previous' track boundaries, the program will no longer stop at the end boundary of that track I was working on.

Seems like something that should/could (possibly) be corrected before the next release? Hopefully, Derek, you'll be able to reproduce the problem. If not, let me know.


PostPosted: Sat Sep 03, 2011 4:20 pm
by Derek
Hi Randy

Yes, this is definitely something that should be fixed. As you say, I don't think it's restricted to the beta.

I'll let you know how I get on.

PostPosted: Sat Sep 03, 2011 4:51 pm
by bmbguy
Honestly, I was quite pleased to finally discover how I was making it happen. Maybe now, at least, I can avoid doing it by keeping the rescan area inside the track boundaries. As I said, it had happened to me a number of times, but I knew it wouldn't be of much help to tell you about it without some idea of what might cause it.


PostPosted: Sun Sep 04, 2011 7:36 am
by Derek
Hi Randy

Yes, I had noticed this very occasionally myself but never managed to get it repeatable. So thanks again for your help with this.

I have now found and fixed a bug but before I release the fix, I need to clarify the problem. You said the problem occurs when the track end and track beginning markers are 'set quite close together'. I could only make the problem occur if the track end and track beginning markers coincide (this happens for example when you use the 'Split Track' command. The bug I found only occurs in this special situation.

Do you think I have found the bug you reported, or is there another one lurking somewhere?

PostPosted: Sun Sep 04, 2011 2:26 pm
by bmbguy

I think you're right, though I'm not sure exactly what you mean by the track markers 'coinciding' -- or at least what the program thinks.

I only use the Split Track function when the program misses a track break, but I do (in most cases) move the end and beginning track markers together until they 'bump' into each other -- that's just me being fanatical and trying to preserve the inter-track timing (the 'feel') of the original vinyl.

So I'm not sure what has to happen to make the track markers 'coincide' in your view, but in the test case I was using, the track markers were indeed VERY close together -- as in, they look joined on the screen, and the 'End of Track 2' and 'Start of Track 3' labels were consecutive in the corrections list. Since I don't know how the markers are represented internally, I can't say for certain that they were 'coincident'. But probably so, from your point of view.

To test your theory, I separated the track markers a bit, and you are right, the problem did NOT occur. I just don't know where that threshold is -- whether or not the problem would still occur if the boundaries were actually separated in samples/time, but didn't have any corrections in between them. When I did the little test by separating the markers, the track markers then had not only time between them, but there were corrections between them in the list as well.

My best guess is that the problem you've found and corrected is likely the same one I was seeing.


PostPosted: Sun Sep 04, 2011 2:34 pm
by Derek
Hi Randy

Yes, sorry, I wasn't very clear. When the markers bump into each other, the actual stored positions do coincide. This gives you a zero length gap, the same as you get when set to gapless.

thanks for the quick response.

PostPosted: Sun Sep 04, 2011 3:31 pm
by Glenn
I experienced this once or twice, but since I've been using gapless track boundaries the issue is very rare.

While we're on the subject of track breaks, what does happen quite frequently is when selecting a block (either for scanning or cut/splice) the block will disappear if one moves across a track boundary. I've since learned to drop cue markers before hand if the block boundaries are critical, but the markers are not visible in track view.

This is an old issue unrelated to the beta. Sorry if I've taken this thread out of context.


PostPosted: Sun Sep 04, 2011 3:46 pm
by Derek
Hi Glenn

I just checked and you're right, the problem doesn't occur if you're in gapless mode. I'm not quite sure why though!

I don't quite follow you're disappearing block description. Can you elaborate?

Also, track markers are visible in track view, or should be. So again, can you elaborate?


PostPosted: Sun Sep 04, 2011 4:05 pm
by Glenn
Derek, if one selects a block that spans a track break, then zooms in to fine tune the block boundaries, in moving between them the programme switches to track view, whereupon the block is no longer visible. I will use cue markers when the selection boundaries are critical, but these are not visible in track view. This itself is no big deal but it is preferrable to avoid track view when setting block boundaries.


PostPosted: Sun Sep 04, 2011 4:54 pm
by Derek
I still couldn't figure out what you meant. But then the penny dropped. The problem occurs if you use the scroll bar or scroll arrow when a block is selected. As you pass a track boundary, the program snaps to it and changes to track boundary view, deselecting the block in the process. Yes, I think I should be able to fix this behavior. Thanks for reporting it.

all the best

PostPosted: Sun Sep 04, 2011 5:08 pm
by bmbguy
As long as we're talking wave/track view here... I just have a question.

When the program is in 'track boundary' view (the track view with the boundary/fade setting capabilities), the user is unable to switch back to 'wave' view without first moving away from the track boundaries.

I'm just curious as to why that is. After I get done setting the boundaries, I always switch back to 'wave' view -- but I always have to double click on an area away from the boundaries before the 'wave' button will take me there.

Is there a reason for this? It's not really a problem (so I'm not suggesting that it be changed), as long as one knows that's the way it works. Although it did confuse me a bit at first, long ago, as I couldn't figure out how to get the program to let me get back to 'wave' mode...

On the other subject, I guess that I use 'gap' boundaries to simulate gapless (end/start boundaries 'bumped' together). I'd probably use gapless more often, but that takes away the ability to do fades in/out (except at the beginning and end of the file, I've found!!). And with the session file name now preserved, it'll be fairly easy to 'mix' gapless and non-gapless processing by using multiple session files on the same wav file!

PostPosted: Mon Sep 05, 2011 6:51 am
by Derek
Yes, this is a little confusing. The behaviour is inherited from early versions of wave corrector that just had wave view and track boundary view, both of which had very limited zoom capabilities. The program snapped to track boundary view when a track boundary was at or near the centre of the screen; and snapped to wave view when you were anywhere else. In current versions, which can zoom to an unlimited extent and which also have 'track view', this behaviour is somewhat anomalous.

PostPosted: Mon Sep 05, 2011 9:40 am
by Derek
Beta3 is now out. it fixes these problems.

PostPosted: Mon Sep 05, 2011 7:06 pm
by bmbguy
Ok, Derek, thanks for the historical/legacy info.

Going to download the new beta right now...

Update: Just FYI - I tried the new beta (3) on that same track boundary area that I was seeing the problem on, and the new version preserved the track boundaries correctly. Woo-hoo!