Talk:Spectral Selection

Bill 19Oct2014: Here's a startSpectral Selection
 * Peter 20Oct14: And a bloomin' good start Bill for what is (for me certainly) a fiercely complex "piece of kit". I've read this page several times now and I still only have a limited grasp of what's going on - down to the complex nature of the tools rather than your explanation Bill.  I think you could do with a bit more in the intro note to explain just why you might need or want to use this for - the example is a good use-case, but that's right at the end when the reader may already have felt TLDR.
 * I made a thorough spell check with Word
 * I added divid anchors for the H2 sections
 * I added a link in the intro to the spectral editing H2 section.
 * Trying out a custom TOC so the user can see what the page covers - remove it if you don't like it.
 * Peter 20Oct14 later: Bill are you planning to provide full separate pages for the spectral editing commands? If not, then this page would probably need to be renamed "Spectral Selection and Editing" or even just "Spectral Editing".
 * Gale 21Oct14: I agree with Peter that more is needed in the intro on what type of audio and what type of glitches therein would benefit from only acting on a selected frequency range. The reason is to get finer control, correct? Also see Click removal using the Spectrogram view. When would one use that Tutorial rather than the tools here? Can you decide what tool to use by inspecting the glitches in Spectrogram View? If so what do you look for?
 * Bill 20Oct14:
 * The click tutorial uses spectrogram view to "see" the click, but does all the work in waveform view. The point of spectral editing is to do all the work in spectrogram view.
 * Gale 21Oct14: OK, though you could (with experience) do the work in spectrogram view there too, unless you actually heard a discontinuity after deleting the click.
 * Bill 21Oct14: I don't think you could do click repair in spectrogram view due to the time smearing inherent in that view.
 * Paul's video tutorial is worth watching and makes the case much better than I could.
 * Gale 21Oct14: But we have agreed not to link to that video, I think. The case needs to be made here and is as yet somewhat unclear to anyone coming new to this idea. Given the steep learning curve the case needs to be extremely clear, or users may not bother with it.
 * Bill 21Oct14: I agree that video as it stands is not appropriate as a tutorial - in it Paul is making a case for the feature, as much to the developers as to the users. If there was a video tutorial it would need to be a new one, done after the GUI and features have been finalized.
 * Paul has said (in one of the -devel threads) that he is using it to remove "mouth noises" from narration. I'd like to see how he does that.
 * Gale 21Oct14: +1. That should be the main use case, shouldn't it, rather than your "artificial" example? The files that contain the mouth noise should be available so that a Tutorial could be written.
 * My example, while somewhat artificial, is based on real experience with old cassette recordings of FM broadcasts that have "multiplex whistle" on them
 * In his video he removes a "clang" from behind his voice - quickly and effectively
 * It's hard to generalize, but I guess I'd say that any time you need to remove an extraneous sound, and the duration and frequency range of that sound can be identified in spectrogram view, then spectral editing is the way to deal with it
 * So the reason is not to get "finer control" but to have a better, faster, more effective work flow.
 * Gale 21Oct14: How is this faster than Paul L's De-clicker and De-esser or something else on an entire track? You know the complaints we get about using Repair on clicks one at a time. The case seems to me that this is "more effective".
 * Let's go to my example. How would I do this without spectral editing?
 * Make a selection then do Plot Spectrum, adjust the plot so I can see the whistle frequency (how do I do that? which controls do I adjust?), use the cursor and the peak display (assuming I've noticed it) to get the exact frequency and write that down, and hope I got the right peak
 * Select whole track and do Effect > Notch Filter; type in the frequency I wrote down and guess at the width factor I need.
 * Apply the effect, listen to the result, and undo and try again - the most likely mistake is to get the width factor too wide and damage the desired audio
 * Gale 21Oct14: I'm surprised that a normal steady noise like hum or whistle can't be picked out in Plot Spectrum. We imply elsewhere that it's easy - yes you may see multiple spikes but you probably want to deal with all of them anyway. So again I find the use case here unconvincing. Not your fault, but the most convincing use case should be presented on this page (I assume that "mouth noises" will be much harder to see in Plot Spectrum, if so that indeed makes the case).
 * Bill 12Oct14: One of the main points is that you don't have to Plot Spectrum, write down a number, do Notch Filter, and guess at the width. You don't have to call up any dialogs at all, and the notch parameters are set for you
 * With spectral editing:
 * Switch to spectrogram view; I can see the whistle right away
 * Drag a rectangle around the whistle, zoom in, refine the rectangle then do Effect > Spectral edit multi-tool; the center frequency and width of the notch are set from the display so I can be confident that I'm removing just the right frequency range
 * I can see right away that the whistle was removed and the desired audio was not appreciably damaged
 * Peter 21Oct14: Bill wrote: "Paul's video tutorial is worth watching and makes the case much better than I could." Having spent just over 32 minutes watching Paul's videos, and having learnt a lot from it, I agree with Bill here - but for most viewers that would be TLDV imo.  Paul falls into the trap of many video tutorials by stating versions of Audacity and those inevitably drift out of date. Plus he includes his extended selection bar without really explaining that it is a non-standard (at this stage anyway) and some unnecessary side issues about Nyquist.  It's hard enough keeping written tutorials up to date, but folk are very un-keen to keep maintaining video tutorials due to the work involved.  Having seen Paul's videos I'm thinking that what we really need is a written tutorial based on the use case that he presented, it's fairly well scripted there - but it will be a lot of work and will end up being a long read.  I am not averse to including a link to a video tutorial, or set of such, from Paul (he presents well and clearly) - but he would need to rework them once the functionality and GUI is finalized for a particular release (each time if it or the surrounding GUI environment changes).