I've been a registered user of WC for a couple of months now, and let me start off by saying that this is a wonderful piece of software, and not only is it useful, it's fun to use as well.

I have a slight problem with it now and then, however. And forgive me if this question has been answered -- I searched the forum, but didn't find a solution.

When I'm working to narrow in on a 'click' that the program didn't eliminate automatically, I sometimes find myself unable to add cue markers -- neither the TAB key or the 'Corrections - Insert Cue' menu pulldown will add one. Nothing happens at all, the program just seems to ignore the command. I am still able to delete other nearby cue markers, but cannot add new ones.

Sometimes, if I go off and start working on a different area of the file and come back to that spot, I'm then able to add a marker, but not always. I've gotten around the issue by saving the session, closing the app, then restarting and restoring the session. Then I'm able to again add cue markers where I want them.

When I'm doing this, I'm typically playing back the same small section over and over, and I'll 'block' out different areas to try to hone in on the spot where the click is. I'm not sure if all that activity has something to do with locking out the cue markets, although there are is no block marked when I actually try to add them.

Just wondering if this is a known issue, and if there is a simple 'out' that would get the markers working again when they get 'stuck'.

Thanks for the response. Just thought I'd 'register' the issue as I see it. As a fellow programmer, I can understand how difficult it might be for you to reproduce it, especially since, as a user, I can't reproduce it 'at will' either.

If you have any sort of debug version you'd like me to try out that might be able to log the program's actions when I get it into that state, I'd be willing to run that for you.

There is a debug version but it's mainly useful when the program crashes, which isn't the case here.

Having looked through the code, I see that there is a restriction that prevents a cue marker being placed within about 250ms of the previous marker. I'm wondering if you are falling foul of this restriction?

From your description, you're using cue markers to 'home in' on a a problem click. That isn't really the purpose of cue markers. They're only designed to provide an approximate location (hence the 250ms restriction). Once you're in the vicinity of the click, the idea is to find it by observation of the waveform and/or the spectrogram. When you think you've found it, a very good way to confirm it is to mark a block over the click in the waveform and then use 'Audition Corrected'. This plays the waveform, skipping over the marked block.

The main problem comes when you have two or more clicks very close to each other. It's then difficult to distinguish them by ear.

I know what the cue markers are used for, but I didn't realize that there would be such a limitation. When I'm trying to narrow in on the click, I got the idea to kind of 'bookend' the area with cue markers, and move them inward toward each other as eliminate spots that I know the click is NOT in. I thought that would be a help to me visually, and it also would help to mark the spot if I didn't get to 'finish' and had to come back to it.

In the scope of things, 250 ms. seems like a pretty large area when you're trying to narrow in on a click, so it's possible that I'm running into that limitation. I guess I was under the impression that you could pretty much mark nearly any spot in the file.

Next time I run into the problem, I'll see if that could be the case -- but I'd swear that I've already put markers closer together than 250 ms.

Oh well -- thanks for your help. It's still a great program!

And while you're working on the next rev, how 'bout a 'color picker' for the main window background, rather than just the three hard-coded defaults? Or even the ability to just enter RRGGBB hex values? I like the 'classic', but I think I'd prefer it if it were just a touch lighter...depends on the monitor.

And if you don't mind my asking, what language/platform did you write this in? I'm just curious, as I've only done Windows code with Visual C++ with MFC.

Also, the technique you described is what I typically use. But I would mark one 'side' of the area first, then the other, to see if I can cut my search area in half -- and then I'd try to move the cue markers that I have delineating my search area. That's when I'd sometimes find that I couldn't place a new marker.

And I know what you mean about two close together -- sometimes they sound like one. And you mark off one, but the click doesn't go away... There are times when I wish I could mark off multiple areas, but that could get to be a 'block' management nightmare.

Yes, the 250 ms is a bit arbitrary. I can't quite remember why it's included but I think it was to avoid multiple cue markers during playback if you left your finger on the TAB key too long.

I'll tidy up this part of the code in the beta when it comes out in a few days. The 250 ms check is only made against the last cue marker that was added. So if you insert a marker some distance away from the point of interest, you should then be able to return and place a marker where you want. This might be worth a try, next time the problem occurs.

Regarding the screen colours, this might have to wait for a future release. the screen colours are hard coded in and it would require a fair bit of work to make them user selectable.

Wave Corrector was originally coded using VIsual C++ v6.0. It has since been moved over to the C++ in Visual Studio 2003. It is an MFC application.

As a registered certifiable chronic (ab)user of WC for almost 5 years, I recommend you try Derek's suggestion regarding the block selection. Just keep repositioning/narrowing the block 'till it's a hair width - there you'll find the troublemaker.

Sometimes it's the only way to find/correct those well masked gremlins.

Thanks -- that's pretty much what I do. I first block out what I think look like the trouble spots (if it isn't immediately obvious). If that doesn't work, I'll block out 'halves' of the screen and work in 'binary search' fashion, zooming in on each repetition. I just got the idea of 'marking' where I've been looking with the cue markers one day, figuring that would help me if I had to walk away and come back to things. And that's when I encountered this little 'gotcha'.

Oh, and I've found that speed control can come in mighty handy during the process as well!