True Peak Detection

[earlevel]

Well, I would argue that it is the absolute worst-case in terms of efficiency and accuracy due to being a brute-force method. So take from that what you will.

8x wasn't a suggestion. It was a suggestion that if the person doing it thought they must do more oversampling than that, they were probably not thinking things through.

[aciddose]

My point is that if a person considers oversampling a solution, they are probably taking the worst possible point of view right from the get-go.

[earlevel]

My point is that if a person considers oversampling a solution, they are probably taking the worst possible point of view right from the get-go.

I'm puzzled at this view. First, it's amusing that you use terms like "very bad", and "worst possible" when considering oversampling (there seems to be an infinite number of poor solutions, most worse than band-limited SRC by a modest factor). But more importantly, I'd consider anything that figures out a realistic peak between samples as an oversampling technique. You're filling in values that you expect will exist between samples when played back through a DAC—how does that not involved SRC in some general manner? (Of course, if you only care about overages (above the max your DAC can produce), you needn't oversample everything, but I'm assuming the general case of wanting to know the precise peak, within reason, between any two samples.)

[aciddose]

Try implementing a few different methods and measure the accuracy/efficiency.

[earlevel]

Try implementing a few different methods and measure the accuracy/efficiency.

I assume you're aiming that at the OP, as I said I have no need...but on my question to you in the last post: "You're filling in values that you expect will exist between samples when played back through a DAC—how does that not involved SRC in some general manner?" (In response to your comment, "My point is that if a person considers oversampling a solution, they are probably taking the worst possible point of view right from the get-go.")

Are we just differing in semantics? To me, if you're figuring out inter-sample values, you're using a sample-rate-conversion technique, specifically oversampling, since the result is having more information than needed to contain the audio.

[aciddose]

It's because you don't have any reason to care about those instants in time, you only care about the peak level. Generating samples does not make any sense whatsoever in terms of solving the problem. All you end up with is a whole bunch of totally useless samples and a fairly poor estimate of the peak level.

Convergence is at best log(N).

It isn't a solution at all it's at best to be considered the brute-force solution for the problem which is the worst-case solution. It is possible to do a whole lot better than log(N) without all the additional overhead or throw-away results.

[earlevel]

It's because you don't have any reason to care about those instants in time, you only care about the peak level.

OK, I mentioned that earlier ("Of course, if you only care about overages (above the max your DAC can produce), you needn't oversample everything...). It's still oversampling, even if you only go after the bits you are interested in.

[aciddose]

You're wrong. In this case you must synthesize samples via interpolation, aka "re-sampling".

A practical algorithm for identifying peak level would not involve any such process and be vastly more efficient and accurate.

There is never a case in which synthesizing samples or "re-sampling" would ever make sense for any purpose other than having a need for such while lacking the ability to develop a more practical algorithm.

There is absolutely no difference between this and brute-force guessing every possible password vs. developing a real algorithm to defeat the encryption.

[earlevel]

You're wrong. In this case you must synthesize samples via interpolation, aka "re-sampling".

A practical algorithm for identifying peak level would not involve any such process and be vastly more efficient and accurate.

There is never a case in which synthesizing samples or "re-sampling" would ever make sense for any purpose other than having a need for such while lacking the ability to develop a more practical algorithm.

There is absolutely no difference between this and brute-force guessing every possible password vs. developing a real algorithm to defeat the encryption.

That made no sense in the context of what I said.

Bandlimited interpolation is not guessing. It's an approximation of what the DAC output would be. And it's less of an approximation than the links you provided to cubic spline interpolation as your first post to this topic.

I'm done here, I think what I've said is clear to most people here, if not to you. My experience is that the exchange will just get weirder and weirder from here and not do a single person any good.

[Mayae]

Not going to dive into the discussion here, but as kryptonaut correctly pointed out in the first page, it really depends on how the signal is further processed. Any realtime DAC is naturally limited in its capability to reconstruct the true waveform of the signal - according to the sampling theorem - and thus ISP's is less of a concern (or at least harder to anticipate the behavior of).

However, for re- or oversampling purposes, any algorithm not based on sinc-resampling would fail in a lot of cases, some of which are presented here: http://techblog.izotope.com/2015/08/24/ ... detection/
Where they also prove that any true peak can have potentially infinite height, in which case any algorithm not considering more than a few surrounding points would give faulty answers..

[earlevel]

Where they also proof that any true peak can have potentially infinite height, in which case any algorithm not considering more than a few surrounding points would give faulty answers..

Well, in that case any practical algorithm would give faulty answers, but of course it wouldn't matter because even the simplest would show a peak high enough to alert the meter watcher that there's a problem.

Interesting that the iZotope article mentioned 4x (without saying it's ideal); I had considered 4x probably good enough, but bumped to 8x (or would have, because I decided to not write the article at that time) to be comfortable that I was giving it a margin of overkill (again this was offline processing—efficiency was not of interest).

BTW, here is the DAC maker's application note, which a well-known producer/engineer friend has posted on FB, that made me think to write the article: http://benchmarkmedia.com/blogs/news/13 ... goes-to-11

So, the fear factor shown in their example is that a sine wave at half-Nyquist frequency and locked at the worst possible phase might be recorded at full cost and give a +3dB over, wouldn't get noticed on the digital meters, sound fine on the studio's expensive DAC, and be a disaster on someone's home or car playback. Of course, even beyond the unlikelihood that this "music" would be pleasant or occur naturally, how much of a disaster would it be for the home user? If it lasted long enough to matter, the distortion would be harmonic and at high frequency (yes, we could talk about non-linearities, but in the end, there's pretty much zero chance that this would happen AND the music would otherwise be listenable).

tl;dr: To be clear, I'm just chatting about this because it's somewhat interesting to think about the inter-sample levels. Do I think such a meter will make a difference in the quality of audio produced across the market? No. Something that sounds good enough and clean enough to have a chance at hearing such problems would not be sustained at full code in the first place, and transient overs are unlikely to be heard unless you have a DAC from hell, in which case everything will sound bad. I don't think oversampled meters are a bad idea, at all, just placing a lot of importance on them is like thinking you need a $1200 ethernet cable http://www.amazon.com/1-5m-Audioquest-D ... iamond+1.5

[aciddose]

I'm not sure why you focus so much on irrelevant "facts" such as anything related to a DAC while you ignore the sampling theorem.

Again, my point is that re-sampling the signal and using these discrete points to approximate the true peak level is the worst possible solution to the problem.

Stop your hand-waving and actually invest some effort to argue the statement I've made here. Can you make any claim that there is a worse algorithm to estimate peak levels?

I don't believe you can possibly do so without simply taking the peak level from the existing discrete signal with no intermediate result or algorithm involved at all.

[earlevel]

I'm not sure why you focus so much on irrelevant "facts" such as anything related to a DAC while you ignore the sampling theorem.

Again, my point is that re-sampling the signal and using these discrete points to approximate the true peak level is the worst possible solution to the problem.

Stop your hand-waving and actually invest some effort to argue the statement I've made here. Can you make any claim that there is a worse algorithm to estimate peak levels?

I don't believe you can possibly do so without simply taking the peak level from the existing discrete signal with no intermediate result or algorithm involved at all.

I really don't know what your problem is. I really don't enjoy discussing things with you, so I'm not going to any more. You say what a worst possible idea it is to use band limited oversampling, but you link to cubic spline approximations.

PS—In my absence, feel free to ridicule the iZotope guys, since the link Mayae provided discusses the same means.

[aciddose]

Are you going to continue to side-step and avoid this, or are you going to actually address the issue and make a valid argument?

Are you going to argue that oversampling is not the worst possible solution?

Will you at least even attempt to disagree that oversampling qualifies as a brute-force solution?

Or from my perspective the best possible direction in which to make your attack would be to disprove that the convergence of oversampling is at best log(N).

[earlevel]

Are you going to argue that oversampling is not the worst possible solution?

Easy: Your solution of cubic spline interpolation is worse.

Now, please go argue with someone else, like the iZotope guys. I have no further interesting in going down this rabbit hole with you. I'm not even developing such a product. I don't care.