Page 1 of 1
Effect on 1.3.8 changes track length???
Posted: Mon Aug 10, 2009 12:48 am
by zzzZZZ
Applying nyquist-plugin on multi-tracks doesn't leave the lengths of tracks as they are.
1. Open several tracks and "select all".
2. Apply any of nyquist plugin.
3. the time-length of All the tracks are to be extend to the longest track.
I'm running version 1.3.8 on vista home premium serv-pack 2.
I'd like to leave each length what they are.
What've I missed? Is there any Preference setting or something? Preceedingly thankx.
Re: Effect on 1.3.8 changes track length???
Posted: Mon Aug 10, 2009 4:19 pm
by steve
You mean that silence is added in the selected empty space?
That's normal. Nyquist treats empty space as if it is silence. The only way to avoid this is to only select the audio that you want to process, and not select additional silence. That may mean that you need to select just one track at a time. Alternatively you can manually trim off any unwanted silence.
This may change in future versions of Audacity.
I'm not sure with "Spectrum Analyzer".
Posted: Fri Aug 21, 2009 5:31 pm
by zzzZZZ
it's really shame. (am i only one who feel it painful?)
but thanks replying anyway.
now here is another problem. isn't something wrong with spectrum?
the magnitude of the overall level on the exact same track widely varies with "window size".
I don't mean that the size of "display window" or its floor level. i mean FFT window; the way of analyzing.
e.g. comes to peak level of the same part of the same track, that shifts -2dB to -34dB with window size. this isn't subtle.
how could audacity calculate the window size? could i compare tracks on this program?
anyone knows?
Re: I'm not sure with "Spectrum Analyzer".
Posted: Sun Aug 23, 2009 2:07 am
by Gale Andrews
zzzZZZ wrote:it's really shame. (am i only one who feel it painful?)
Quite a few problems would be solved if Audacity treated white space and silence as the same thing for its own functional purposes, but we agree that clips should be preserved. Another workaround apart from processing clips separately is to Edit > Detach at Silences after processing all the clips together, which is obviously more convenient.
zzzZZZ wrote: now here is another problem. isn't something wrong with spectrum?
the magnitude of the overall level on the exact same track widely varies with "window size".
I don't mean that the size of "display window" or its floor level. i mean FFT window; the way of analyzing. e.g. comes to peak level of the same part of the same track, that shifts -2dB to -34dB with window size. this isn't subtle. how could audacity calculate the window size? could i compare tracks on this program? anyone knows?
It's about "frequency bins". A sine wave should show about the same amplitude with different window lengths, because it falls in one frequency bin. We've tried to make it in 1.3.8 so that an amplitude 1.0 sine wave shows at 0 dB.
But if you have a random signal like music, you can expect the amplitude to fall by 3dB for every doubling of the FFT size, since the bins are half the size and so contain only half the energy.
There is a
PDF you can read (needs a
plug-in).
Gale
Re: Effect on 1.3.8 changes track length???
Posted: Mon Aug 24, 2009 2:10 pm
by zzzZZZ
Quite a few problems would be solved if Audacity treated white space and silence as the same thing for its own functional purposes, but we agree that clips should be preserved. Another workaround apart from processing clips separately is to Edit > Detach at Silences after processing all the clips together, which is obviously more convenient.
thanks for your suggestion. that might the way of what we have now. I'll give it a try.
[[P.S.]]
can we export without the detached segment? when I tried that command and exported as WAV, blank part came back...
I messed up something? or should I wait next version?
It's about "frequency bins". A sine wave should show about the same amplitude with different window lengths, because it falls in one frequency bin. We've tried to make it in 1.3.8 so that an amplitude 1.0 sine wave shows at 0 dB.
But if you have a random signal like music, you can expect the amplitude to fall by 3dB for every doubling of the FFT size, since the bins are half the size and so contain only half the energy.
There is a PDF you can read (needs a plug-in).
your pdf wouldn't open. the API doesn't work on my adobe reader. I gotta be useing ver. 9.0.
(sorry I'm not familiar with adobe because I always use foxit reader. but I've tried in several way).
so could you show me the other way to get that document?
btw. "frequency bin"=(sampling/clock)/(data points of FFT), am I right?
are there any other leakage...?
Re: Effect on 1.3.8 changes track length???
Posted: Thu Aug 27, 2009 2:08 am
by Gale Andrews
zzzZZZ wrote:can we export without the detached segment? when I tried that command and exported as WAV, blank part came back...
Isn't that expected? A WAV does not understand clips in a track, so the space between the clips must be silence. You can export only one clip by double-clicking to select it then File > Export Selection As.
zzzZZZ wrote: your pdf wouldn't open. the API doesn't work on my adobe reader. I gotta be useing ver. 9.0.
You have to install the
plug-in as I said. Version 9 won't help without the plug-in.
zzzZZZ wrote: "frequency bin"=(sampling/clock)/(data points of FFT), am I right?
are there any other leakage...?
I'm actually not an expert in this field so it's easier if you read the PDF. But if you read it and you still have questions, you can ask then.
Gale
Re: Effect on 1.3.8 changes track length???
Posted: Thu Aug 27, 2009 6:15 am
by zzzZZZ
Isn't that expected? A WAV does not understand clips in a track, so the space between the clips must be silence. You can export only one clip by double-clicking to select it then File > Export Selection As.
I see. Thanks for detailed explanation. Probably I should wait next version to handle parallel tracks.
You have to install the plug-in as I said. Version 9 won't help without the plug-in.
zzzZZZ wrote: "frequency bin"=(sampling/clock)/(data points of FFT), am I right?
are there any other leakage...?
I'm actually not an expert in this field so it's easier if you read the PDF. But if you read it and you still have questions, you can ask then.
Sorry for the lack in wrote. It's my fault. The "API" is the type of the plug-in which you introduced me. And it dosen't work on my system from compatibility to my adobe or system or something...
But now I understand I should, one way another, read that file on "Audacity's calculation of FFT (...right?)".
Thanks for everything.
Power Spectrum Estimation using FFT
Posted: Wed Sep 02, 2009 12:16 am
by Gale Andrews
zzzZZZ wrote:The "API" is the type of the plug-in which you introduced me. And it dosen't work on my system from compatibility to my adobe or system or something...
But now I understand I should, one way another, read that file on "Audacity's calculation of FFT (...right?)".
That PDF does not even allow selecting and copying the text but I found an
online version of it.
Gale
Re: Effect on 1.3.8 changes track length???
Posted: Wed Sep 02, 2009 6:50 am
by zzzZZZ
It's very kind of you. That book is the ROCK! Thanks.
(That API didn't run on my system in the long run. This post is surely a help.)
I'll read it through. but before that,
Can I assume Audacity's FFT implement is correctly based upon this book.
As far as a glance there seems no detailed reference to window functions (if there's, sorry). Can I presume you using general functions; square(rectangular)=1.0, hanning=0.5-0.5*cos2piA, hamming=0.54-0.46*cos2piA.
Seems to me that chap.13 has little with this issue and I won't take it in account that much. Can I?
I have a for-testing white noise track which has constant magnitude through frequencies upto 20k and alters it's form at my will. If there's any unexpected leakage on your FFT I'll let you know (Main HP?). But it probably takes a while, of course, I'm sorry about that.
Re: Effect on 1.3.8 changes track length???
Posted: Wed Sep 02, 2009 12:15 pm
by steve
zzzZZZ wrote:Can I assume Audacity's FFT implement is correctly based upon this book.
Audacity's FFT implementation was recently updated, and that paper was cited as the explanation of why the current implementation differs from the earlier one - so I guess the answer is yes, the current implementation is in line with the book.