View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002782 | ardour | features | public | 2009-07-17 14:01 | 2010-07-21 15:48 |
| Reporter | oofus | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Platform | Dell D830 core2duo T9300 2.5GHz | OS | Mandriva | OS Version | 2009.1 |
| Target Version | 3.X | ||||
| Summary | 0002782: Request for more accurate clipping detection with meters and particularly region waveforms. | ||||
| Description | Currently clipping is assessed on a single sample basis and the threshold is set just below 0dBFS. It is perfectly possible to have material that is just under 0dBFS but is not clipping. Importing this material currently shows a red clip indicator in the waveform for the whole length of the waveform. This is wrong, nothing is clipping. The suggestion is that only 3 consecutive samples of 0dBFS be considered as a clip. The following conversation was had on IRC and adds more detail to the request. [14:19] <oofus_lt> las: Morning. Just out of curiosity, could you point me at the code that figures out if audio in regions is clipping or not and then adds the red peak to the waveform. [14:23] <flower> does FST use wine? [14:24] <hollunder> it's for windows VSTs, right? So yes [14:25] <flower> ok [14:31] <las> oofus_lt: that would be in canvas-waveview.c [14:31] <las> oofus_lt: look for a function whose name ends in _render [14:31] <las> oofus_lt: its very hairy code, i warn you [14:32] <oofus_lt> las: hmm, ok [14:32] <oofus_lt> las: need an option to turn it off then [14:32] <las> oofus_lt: that will be tricky [14:33] <las> oofus_lt: that code is C, not C++ [14:33] <las> oofus_lt: so you can't just access Config->get_oofus_s_new_idea() [14:33] <las> oofus_lt: why do you want to turn it off? [14:33] <oofus_lt> las: I've been importing stuff that I know hasn't got any clipping in it (it gets close) and the waveforms are all tipped with red. It looks horrible and is wrong. [14:34] <las> oofus_lt: oh, question for you ... in the daw's you know, how do you do a cut that "closes" the gap afterwards [14:34] <las> oofus_lt: ah, yes, the clip indicator is set to just very very very slightly below 0dBFS [14:34] <las> oofus_lt: what would be better than turning it off, perhaps, is being able to set the level [14:34] <oofus_lt> las: not sure I understand that question [14:35] <las> oofus_lt: select-range-of-audio / "cut" / move later audio left to butt up against earlier audio [14:35] <oofus_lt> las: it's not just the level, it should only show a clip if a number of samples are at 0dBFS. [14:35] <las> oofus_lt: or is this only an editing mode thing, and in some modes "cut" never does this [14:35] <oofus_lt> las: with that number being 3 or 5 or similar [14:35] <las> oofus_lt: hah! the old "short" and "long" over idea from bill gribbl [14:35] <las> e [14:35] <las> oofus_lt: ardour used to have configurable short/long "overs" [14:35] <hollunder> oofus_lt, optimally configurable [14:35] <las> oofus_lt: i.e. the number of samples to count as each kind of "over" [14:36] <hollunder> 3 seems to be some kind of standard but taste certainly varies [14:36] <las> oofus_lt: here's the thing: doing that with peak data is unreliable [14:36] <las> oofus_lt: you are not looking at the sample data [14:36] <las> oofus_lt: we used to apply this to the actual meters in the strips [14:36] <oofus_lt> las: ah yes, peak files. [14:36] <las> oofus_lt: there were two indicators of clipping, one for short, one for long [14:37] <las> oofus_lt: i really don't think you can do this correctly with waveform displays without adding more data to the peak files [14:37] <las> oofus_lt: and that would be pretty hairy, though not totally impossible [14:38] <oofus_lt> las: in answer to your other question, generally I wouldn't expect cut to move the remaining audio to butt up against each other, I would expect to just be left with a hole. [14:38] <oofus_lt> las: it has to be an editing mode [14:38] <las> oofus_lt: i.e. a peak datum is actually 3 values: min, max and a sample count if abs(min) or abs(max) exceeds the cliplevel [14:39] <las> oofus_lt: there are lots of people who are used to sndfile editors who expect the opposite. [14:39] <oofus_lt> las: which you already have with splice edit [14:39] <las> oofus_lt: its not too hard to give it to them, but the non-shuffle mode needs to be available at the same time, all the time [14:40] <oofus_lt> las: I can't think of any DAW that I've seen that does that by default, if at all [14:41] <las> oofus_lt: regarding the clipping stuff, would you mind explaining why single sample clips don't matter? [14:41] <las> oofus_lt: also, i think the right "fix" for now is to make the level configurable [14:42] <las> oofus_lt: if you look in canvas-waveview.c, pick one of the waveview's parameters (e.g. bg color or something). you can search through the code and see how to add a new parameter, set it and get it. then just make the clip level configurable. [14:42] <oofus_lt> las: a single sample at 0dBFS might be the very top of a signal that isn't clipping. A sample at 0dBFS isn't clipping, [14:42] <oofus_lt> it's just at the highest level it can be [14:44] <las> oofus_lt: ok, yes, i am familiar with this argument [14:45] <las> oofus_lt: the problem is that in the real world, it doesn't work [14:45] <oofus_lt> las: why's that [14:45] <las> oofus_lt: there are plenty of D/A converters that get this wrong and cause clipping at the conversion stage [14:45] <las> oofus_lt: this is not the SSL "inter-sample clipping" theory [14:45] <las> oofus_lt: just actual sloppy electronics [14:45] <las> oofus_lt: it doesn't apply to apogee :) [14:46] <oofus_lt> las: well, that's a different problem. That, as you say, is just bad electronics. [14:47] <oofus_lt> las: Why should a meter or waveform show incorrect clipping just to compensate for poor electronic design ? [14:47] <las> oofus_lt: because probably 85% of all ardourians have such electronics? :) [14:47] <petern_> hmm, i was under the impression that it was standard for clip detection (on digital) to have the 3 sample thing [14:48] <hollunder> it's not SSL's theory ;) [14:48] <las> petern_: yes, it is. but we've found that it doesn't actually work well enough on a lot of common h/w [14:48] <las> hollunder: do you have a better origin story for that one? [14:48] <hollunder> petern_, afaik that comes from sony [14:48] <oofus_lt> las: but in that case their hardware might start clipping at -10dBFS, do you start indicating that, just in case ? [14:48] <las> oofus_lt: hence "make the clip level configurable" :) [14:48] <oofus_lt> las: ok [14:48] <las> oofus_lt: and file a feature request in mantis with this conversation cut-n-pasted [14:49] <oofus_lt> las: ok [14:49] <las> oofus_lt: the real-time metering thing just seemed not worth it, so i removed it a couple of years ago [14:49] <hollunder> las, I only recently found the SSL thing. They state one of Bob Katz's articles as background info in their manual and I'm quite sure I also read about it in some AES paper [14:49] <las> oofus_lt: it added elements to the GUI that people found confusing [14:49] <oofus_lt> las: like what ? [14:50] <las> oofus_lt: i guess the problem was that i tried to display both short&long overs [14:50] <oofus_lt> las: ok [14:50] <las> oofus_lt: if it was restricted to a single one, then the current numeric/clip level indicator could be used [14:50] <oofus_lt> las: just what I was going to type :) | ||||
| Tags | No tags attached. | ||||
