This could be of interest:
http://conf.e-jikei.org/ICTSS2018/proceedings/materials/proc_files/IPS03/IPS03_08_ICTSS2018.pdf
The authors compare three algorithms generating low-crest multitone signals and in addtion show the higher crest factor resulting from the use of random phase combinations.
http://conf.e-jikei.org/ICTSS2018/proceedings/materials/proc_files/IPS03/IPS03_08_ICTSS2018.pdf
The authors compare three algorithms generating low-crest multitone signals and in addtion show the higher crest factor resulting from the use of random phase combinations.
Or maybe you mean that composition of spectral components of various phase may lead to excessive amplitude (= clipping) in time domain, though amplitude spectrum of signals is same? I know this fact and have some simulations as well.
Attachments
Last edited:
Whatever way one reads it, your quote is supporting exactly what I was saying all along: "output signal under steady-state conditions" not "system under steady state condition". For all those that can tell their *** from a hole in the ground (you excepted) the difference is obvious, and it is not semantic only.
The rest of your rant is distorted drivel that doesn't deserve a response.
Geeez you guys are killing me with minutia ---- Lets get some tangible results/data.
THx-RNM
THx-RNM
Yes, I have the original papers on crest factor reduction some of this was used in ADSL. There are many solutions in between that still look noise-like but have large peak values. The key is that for random noise to make one of these very regular arrangements by chance is spectacularly small, think 5 sec of white noise forming "Mary had a little lamb".
Last edited:
Is crest factor important because a) we don't want to drive a device into clipping b) music can have a high crest factor (up to 20dB - Sinewaves only 3dB (not even up to the 6dB crest factor of very compressed music) - so are not exercising the device in the way music is?
How important is crest factor (apart from avoiding clipping) given that sine waves are accepted?
How important is crest factor (apart from avoiding clipping) given that sine waves are accepted?
For the immediate purpose I would say b, clipping and inter-sample overs are a failure of the system I would hope we are looking for more subtle things.
So could it be ensured that crest factor stays lowish to avoid clipping even though we can't ensure that it remains at the same dB level
Agreed. I can't wait to see results/data about what a measurement with a single cycle input signal (sine, square, triangle, whatever) is revealing, and the periodic equivalent signal is not.
I'm not holding my breath for an answer.
You can tune the crest factor to anything you want within the limits, 1.66 on the low side and all tones in phase on the other. The 1.66 comes from the algorithms in the paper Jakob posted earlier, this is very low the expected crest factor of random noise is around 3.1. I don't know why that paper did not make that point there is no difference if you sum sine or cosine waves, if you generate enough multi-tone waveforms with random phase the expected value will approach 3.1. The derivation of this number would just bore most here.
Last edited:
Pretty trivial if one considers passing a random variable through a deterministic sine/cos function, and recalls that a a random distribution has the RMS equal to its variance. Nonetheless boring 😀.
Yes, of course.....exept when you were saying something completely different, like
"A "steady state measurement" is by definition a measurement taken on a DUT, when the DUT doesn't change in any way during the measurement."
or
"The quote is correct; the "system" must be under steady state, not the "measurement""
or
"using sine waves is the usual way to measure a system in steady state"
a new spin every day, isn't it?
"Of course, how convenient
." (copyright: syn08) @ scott wurcer,
I thought so (and so do I) but suspected that some other might not have those original papers, so this open access one could be of interest....
Of course, it is a bit like the old example of monkeys randomly typing on a typewriter but compiling "Hamlet" by accident. 🙂
Last edited:
Yes, thank you, this paper shows a good summary of what has been done. As I said they don't elaborate much on the distribution of totally randomly generated multi-tones.
I'd basically agree to the "minutia" at this point (already two days ago afair), but please consider that syn08 was shouting "FUDing" at me, when writing something like:
"using sine waves in the usual way is steady state measurement"
while he thinks that writing something like this:
"using sine waves is the usual way to measure a system in steady state"
were absolutely correct and of course not "FUDing".
In addition he has the nerve to accuse me of playing the "potato or potatoe"
game.....
In a broader sense it is a bit more than "minutae", because he thinks it is his absolute privilege to shout "FUD" (along all other nice insinuations he constantly uses) at every member expressing something that he don't like.
Even if it is such a ridiculous case like this one; it is just a simple case of him following his agenda (something like rescuing this poor forum from "audiophile uberdrivel" ) .
If a religious like goal like this is combined with a near total inability to admit having erred, it is exactly what you get.
I can't say, if the approach to expose the "spin doctors doing" will really help/work, but imo there is quite a lot of evidence that letting a bully bullying does not restrain him from doing so and even ramp it up.
All clear, your distortion of reality is intended only to stir the pot, since nobody sane can misunderstand my quotes. I no longer fall for this BS, go ahead, you have the last word.
No I haven't. YouTube I've seen Walkabout 🙂
Whilst hitchhiking in Australia with my Australian girlfriend we were picked up by an aboriginal taken to his home, fed, given a bed for the night, breakfast in the morning and dropped off down the road. She was in her early thirties and said that was the most contact she'd ever had with aboriginals.
- Status
- Not open for further replies.