Trouble Adding Cue Markers

[bmbguy]

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 your help!

[Derek]

Hello and welcome

No, I wasn't aware of this problem so I can't offer an immediate solution. As I'm currently working on the next version of Wave Corrector, it's a good time to try and fix it.

I'll have a go at reproducing the problem but it would be easier if you were able to give a precise sequence of steps that always causes the problem to occur.

all the best

[bmbguy]

Derek,

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.

[Derek]

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.

Sorry to ramble, but I thought it might help.

regards

[bmbguy]

Derek,

Thanks for that info -- that's something I'll keep in mind.

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.

[bmbguy]

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.

[Derek]

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.

[bmbguy]

Ahh, that makes more sense on the 250 ms. thing, if the comparison is only against the most recently added marker. I'll give that a try next time I encounter the problem.

If the app is coded in VC++, there are quite a few 'color picker' classes out there that could make the user selection job easier if/when you decide to look into it. (codeproject.com).

Thanks for the info!

[bmbguy]

Derek,

I'm not sure that the 250 ms. measuring stick is right, but it seems to be the right idea.

I did a little experiment:
I put a marker at 17.623s, then --
was not able to place one at 17.653
was not able to place one at 17.678,
but WAS able to place one 17.712.

Second experiment:
Put a marker at 17.918, then
was unable to place one at 17.951,
but WAS able to place one at 17.984.

So you steered me in the right direction -- it does seem to be dependent on where the last one was placed, but that interval looks to be smaller than 250ms -- something less than 100 ms.

At least now I can move away from the current spot, place a marker, and then move back if I find that I just HAVE to put a market down somewhere...

[Glenn]

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.

Glenn

[bmbguy]

Glenn,

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!

[Derek]

Yes, looking again I see that the limitation is not 250ms but nearer 60ms, but the rest of the explanation stands!

In the beta, I've removed removed the restriction except when you add a cue marker during playback.

I expect to release it in the next day or two.

all the best and thanks for bringing this to my attention.

[bmbguy]

Derek,

That sounds about right -- it looked to me to be > 50ms but < 100ms.

I understand your rationale for the limitation, and for those reasons, enforcing it only during playback makes perfect sense.

Thanks for all your help.