Problem occurs in 2.0 on Win 7 Pro x64 installed with the .exe installer.
The thread title basically says it all. I frequently used contrast analysis in the beta, now it’s not working anymore. Regardless of what I do, whenever I click the “Measure selection” button in the Contrast Analysis box, I get an error message “you can only measure on track at a time” (yes, i know) and a contrast analysis result of “Please enter valid times.” Needless to say, I do enter valid times.
Thoughts?
The Contrast tool only works on mono tracks.
I’m unsure if the tool was ever intended to work on stereo tracks. Did it work on stereo tracks in your previous version? Do you know the exact version number that you were using previously?
Previously, Contrast measured the bottom track in the project irrespective of which track was selected. If you only had one stereo track, Contrast would just analyse the bottom (right) channel. If you had five stereo tracks, it analyzed the right channel of the fifth stereo track.
Contrast was then fixed so that it only measured a single selected mono track.
So to measure contrast on a stereo track now, use the Track Drop-Down Menu to “Split Stereo Track”, then you can select and analyse one channel of the track or the other.
Gale
Thank you very much!
The Manual says:
http://manual.audacityteam.org/man/Analyze_Menu
“Contrast Analysis is designed to analyze a single mono or stereo speech track”
So if it would be possible, could someone make it work so that it works again on stereo tracks (both Windows and Mac and Linux versions)?
Thanks for the reminder that we did not update the Manual, which I have now done. The Manual was wrong in suggesting that “if you have multiple tracks open, Contrast Analysis will calculate rms values based on all of the tracks, whether they are selected or not” - as above, it analysed only the bottom track or channel.
As above, it never did analyze a stereo track, only the bottom (right) channel of it. Averaging out rms in multiple tracks would mean more coding and complexity which might not be worth it. And if the user has selected multiple tracks, it probably isn’t useful for Contrast to make a decision to operate just on the bottom one.
I agree it would save user’s time that if an unsplit stereo track was selected, Contrast simply went ahead and analyzed the right channel with an appropriate message. But again this may mean significant new coding.
Gale
Hey Gale. Can you change it so, that it calculates both channels (so just does two passes, first left and then right), then just adds them together and divides the result by 2 for an average? (a+b)/2
That probably isn’t the correct way to handle stereo tracks, but more importantly the WCAG 2.0, Success Criteria 1.4.7 does not specify how stereo sound should be handled. http://www.eramp.com/WCAG_2_audio_contrast_tool_help.htm
For example, if a voice is panned to one side and background music is panned to the other side, then it will probably be easier to pick out what the voice is saying (less contrast) than if both voice and music are panned centre.
(The other issue is that neither Gale nor myself are Audacity developers.)
Yes, so if you split the stereo track then run Contrast on each channel, it isn’t easy to interpret the result.
It’s also unfortunate that for most of the examples WCAG actually show a selection in a stereo pair, which now won’t work and which scenario wasn’t considered by them.
Gale
So it appears that they were working on the assumption that stereo tracks are fairly similar in both channels?
If that’s the case, what was the reason for the “fix”?
Maybe, I don’t think anyone even considered or raised it.
Probably because you raised a bug report for it ( http://bugzilla.audacityteam.org/show_bug.cgi?id=454 ). I haven’t officially “approved” the fix yet, as you can see, but you can say that about other bugs too because I am short of time.
Martyn did not answer any of my questions about his fix in comment 3 so I guess we’ll close that bug, raise new bugs for the other issues that were found in testing the fix, and decide if the loss of analysing the bottom half of an unsplit stereo pair is worth a new bug. I think I would favour a message (when a single stereo pair is selected) “Stereo Pair selected. Contrast can only measure one selected channel at a time. Press “Cancel” then use the Track Drop-Down Menu to “Split Stereo Track”, or press OK to analyze the bottom channel only.” Or forget the second sentence and the “Cancel” button and just analyze the bottom track when they press OK.
I didn’t get any reply when I asked David MacDonald about wrongly stating that you can select track using the TimeText controls in Contrast. However I’ve now also asked him about the implications of only analyzing half a stereo pair or doing both.
Gale
The original bug report was that the “wrong” track was sometimes analysed (the bottom track, regardless of which track is selected).
WCAG 2.0 does not appear to specify what should happen in the case of stereo tracks. Neither is it clear whether rms weighting should be used, though the linked documentation suggests C weighting. The current effect measures unweighted rms.
In the absence of a clearly defined standard I would suggest that the best option would be that, in the case of stereo tracks, the plug-in should measure the root of the average squared sample values (all selected samples).
I have raised bugs 511, 512 and 513 regarding the known problems so Bug 454 can probably be closed now.
Probably, but if that is possible do we then retain the restriction on only analyzing one track at a time? A selected left and right channel would be the same as a stereo pair. Does it then become meaningful to analyze multiple tracks before mixing them, and what if the user has moved the gain or pan sliders?
Thanks for that. I resolved-fixed #454 and commented in http://bugzilla.audacityteam.org/show_bug.cgi?id=511 .
Gale
For a single track the gain slider is not relevant because the pass/fail is only concerned with the relative rms level of the foreground level to the background level. The absolute level is unimportant.
For multiple tracks the situation becomes much more complicated and I see no clear case for what the effect should do. The user may want per track readings or they may want one reading for the mix. I would suggest that if a user wants a reading for a multi-track mix, then they should use Ctrl+shift+M to create a mix track, then select and analyse the mix track (then Ctrl+Z to undo the mix track).