Sorry for my poor math/music knowledge..
Assumed whe want to play a video file at 50% and at 75 % speed how much cent do I have to shift in both situation to keep the same pitch and what would be the formula?
Thanks in advance!!
reducing the frequency by 50% means the sound is one octave lower
one octave is 12 halve-tones
1 halve tone is 100 cents
so if you play it at 50% you need to pitch it up by 1200 cent
Related
my BH1750 I2C light sensor is giving me a reading in lux but I need a lumen-value.
From what I read I just multiply the lux-reading by the surface area of the sensor to get my lumen-value.
But from the datasheet on page 6 I'm getting a very small surface area of 0.25mm by 0.3mm. That doesn't seem right. What am I doing wrong?
I'm getting a reading of about 8,000 lx on this cloudy afternoon which should be somewhere around 600 lumens.
You seem to have a wrong understanding of photometric quantities. Let me try to get this straight with an analogon: Consider a water fountain that emits water. This fountain will stand for our light source.
The total amount of water that the fountain emits can be measured as m³/s (cubic meters per second). This is a characteristic of the fountain, which could be called the water power. Going back to photometry, this power is equivalent to the luminous flux, which is measured in lumen. Therefore, the luminous flux describes how much light a light source emits. You can restrict this definition to a given set of directions (e.g., measure the luminous flux of a light bulb only in a downward cone). This will give you the total amount of light that travels in that cone. For the fountain example, this can be done equivalently. Just measure the water emitted into a given cone. The unit is still m³/s or lumen.
Now, let us not only consider the fountain (as the light source) but also the surrounding surfaces. We can pick an arbitrary point on the surrounding surface (a point with no area) and measure how much water/light arrives at this point. This might be a bit hard to imagine because it is a differential quantity. You can approximate this value by measuring the amount of water that arrives in a small neighborhood of the point and dividing by the area of that neighborhood. This is actually what your sensor is doing. The resulting unit is m³/s/m² (cubic meters per second per square meter) or for the photometric case lm / m² (lumen per square meter), which is the definition of lux (unit of illuminance). Therefore, different points can have different illuminance. Especially, points far away from the light source usually have a smaller illuminance. You can calculate the total luminous flux by integrating the illuminance of the entire surface area. This is equivalent to measuring the amount of water at very many small surface pieces around the fountain (i.e. illuminance multiplied by area) and summing them up.
With this background knowledge, we see that it does not make sense to convert lux to lumen. They measure completely different things. Intuitively, illuminance tells you how much light shines at a given point, which is usually what you want. What you did (by multiplying the illuminance by the sensor area) is calculating the total luminous flux that arrives at the sensor (total amount of water at a given surface patch). Naturally, this measure grows as your sensor gets bigger (there will be more light arriving at the surface; or equivalently, as you consider bigger and bigger patches around the fountain, you will collect more and more water). Therefore, it does also not make sense to state that 8 klx should be 600 lm.
Related to this extremely helpful question regarding finding the azimuth & elevation of the sun for a given date, and coordinates. I wish to find the inverse: times & dates the sun will be in that position of the sky.
Therefore I am wondering could someone help with maybe an existing formula or modifying the one linked to.
My current idea was to take two ranges with a variation of a couple of degrees for both, one for the azimuth (120-123 degrees) and elevation (18-21 degrees). Then write an algorithm to iterate through all days / times, and check if the given ranges exist for a time on that day. Looping through these days and using the attached algorithm isn't exactly going to keep Big O small, and also won't be best for performance.
Any help or tips appreciated, please.
Thanks.
There is some useful stuff here (see the links - in particular [12]-[15])
https://en.wikipedia.org/wiki/Position_of_the_Sun
One problem is if you are using this to determine things like "which days would the sun be directly over the 'Heel Stone' at Stonehenge in Z-thousand BC", then there will be a lot of sources of errors beyond precession and/or nutation (earthquakes change the earths rotation period, when the Sun is close to the horizon you'll get some significant refraction). There is also http://www.stargazing.net/kepler/sun.html . However, as there are many days and times when the sun is in a particular position, the method of guessing a window of date and time and then doing a Newton-style approximation iteratively is probably best. Perhaps if you could give more information as to why you are trying to find the answer (i.e."when does the shadow of the oak tree fall on the buried treasure..."), we could be more helpful?
After some thinking you can get the date like this:
if (ang>=0.0) date = (21.March) +ang*(21.June -21.March )/(23.4 degrees);
else date = (21.September)-ang*(21.December-21.September)/(23.4 degrees);
dates are pretty straight forward
ang is the current angle between the ecliptic plane and Earths equator plane
must be measured during day !!!
if you measure the suns height (at your latitude) at astronomical noon then:
ang = height - (90 degrees - your latitude)
to convert height measured at any time you need to apply vector math
see computation of angle between two planes
see image for more clarity
To compute time during the day you will need to look for
conversions between standard (UTC) time and stellar time
also a good idea is to look for solar clock design which includes all computations in geometrical manner.
Do not forget that this approach do not include precession, nutation ...
if you account for that then this task become unsolvable because of sun sky-dome path crossing which leads to multiple solutions for any given suns position
luckily precession is too slow and we can skip it for few thousands years
and nutation has small radius (affect accuracy only)
So I am working on a simulation of the solar system and ran into a roadblock...
In reality, the speed of the moon compared to the earth is much slower then that of the earth compared to the sun. However, the moon completes its orbit much quicker because it has to travel much less distance. The moon orbits the earth about 13 times in 1 year.
In my simulation however, the moon gets maybe 2 orbits in a year...
I've checked the speed with wikipedia and they are correct.
The only difference is that I scale everything, making me suspect that that's the cause.
All distances are devided by 100 000 and all speeds are devided by 1000
this.angle += (speed * deltatime);
this.x = this.semi_major_axis * Math.cos(this.angle) + this.parent.x + this.focalX;
this.y = this.semi_minor_axis * Math.sin(this.angle) + this.parent.y + this.focalY;
Speed is the speed according to Wikipedia. (29.78 km/s for earth and 1.022 km/s for the moon)
Parent in this case means the object it is orbiting (in case of the earth, it's the sun. In case of the moon, it's the Earth)
focalX and focalY are the offset from the planet.
Speed and the 2 axis values are already scaled at this point.
Am I wrong in the manner of the scale? Am I completely missing something obvious? Am I just doing it completely the wrong way?
Since speed is distance/time (eg kilometres/second) when you scale speed by 1000 and distance by 100000 you have, whether you know it or not, scaled time by 100. Are you sure that you have taken this into account in the rest of your calculations ?
And yes, you are approaching this entirely the wrong way. If you were building a mechanical simulator you would want to scale distances quite early in the process, but in a numerical simulator why scale them at all ? Just work in the original units.
Since you don't have a computer screen which is several AU (astronomical units) across, you might have to scale the numbers for imaging but most graphics systems will do that for you at some point in the pipeline.
I'd say you should go through the exercise of non-dimensionalizing the original equation of motion, similar to what people do with Navier-Stokes equation for fluids (it's a good example to look for). You'll see that non-dimensional groupings should turn up, like the Prandtl and Reynolds numbers for fluids, that will give you meaningful insight into the problem AND make your numerical solution more tractable.
I don't think it'll be the scale, the simulation will do those distances 100 times quicker than is accurate (big drop in distance, small drop in speed), but it should be uniform across the board so the Earth and Moon will both speed up by the same amount, I'd look at the base speeds again and make sure they're correct and also your algorithm that calculates distance travelled.
I'm a beginner with FFT concepts and so what I understand is that if I put in 1024 signals, I'll get 513 bins back ranging from 0hz to 22050Hz (in the case of a 44100Hz sampling rate). Using KISS FFT in Cinder the getBinSize function returns the expected 513 values for an input of 1024 signals. What I don't understand is why duplicate peaks show up. Running a test audio sample that goes through frequencies (in order) of 20Hz to 22000Hz I see two peaks the entire time. It looks something like:
_____|________|_____
As the audio plays, the peaks seem to move towards each other so the second peak really does seem to be a mirrored duplicate of the first. Every example I've been through seems to just go ahead and plot all 513 values and they don't seem to have this mirroring issue. I'm not sure what I'm missing.
Ok, after reading up on this I found the solution. The reason for the mirroring is because I use an FFT on real numbers (real FFT). The normal FFT as everyone knows works on complex numbers. Hence the imaginary part is "set" to 0 in the real FFT, resulting in a mirroring around the middle (or technically speaking the mirroring is around 0 and N/2).
Here is a detailed discussion: http://www.edaboard.com/thread144315.html
(the page is no longer avaliable, but there is a copy on archive.org)
And read p 238 - 242 on this book (Chapter 12). It's fantastic, so buy it. I think there is a free pdf version on the author’s website: http://www.dspguide.com/
You are possibly plotting the magnitude of all 1024 FFT result bins of a 1024 length FFT, but the upper half is just a mirror image of the lower half (since real-only input to a complex fft doesn't provide enough degrees of freedom to make the upper half unique).
The peaks will move towards each other when mirror images of each other about the center.
Another possibility is that your FFT was somehow only of length 512.
I would like to create a digital (square) signal on my sound card. It works great if I generate high frequencies. But, since I can't output DC on a sound card, for lower frequencies the resulting digital bits will all slowly fade to 0.
This is what the soundcards high pass does to my square wave:
http://www.electronics-tutorials.ws/filter/fil39.gif
What's the mathematical function of a signal, that, when passed through a high pass will become square?
Ideally, the solution is demonstrated in gnuplot.
The sound card cuts out the low frequencies in the waveform, so you need to boost those by some amount in what you pass to it.
A square wave contains many frequencies (see the section on the Fourier series here). I suspect the easiest method of generating a corrected square wave is to sum a Fourier series, boosting the amplitudes of the low frequency components to compensate for the high-pass filter in the sound card.
In order to work out how much to boost each low frequency component, you will first need to measure the response of the high-pass filter in your soundcard, by outputting sine waves of various frequencies but constant amplitude, and measuring for each frequency the ratio r(f) of the amplitude of the output to the amplitude of the input. Then, an approximation to a square wave output can be generated by multiplying the amplitude of each frequency component f in the square wave fourier series by 1/r(f) (the 'inverse filter').
It's possible that the high-pass filter in the soundcard also adjusts the phase of the signal. In this case, one might be better off modelling the high pass as an RC filter, (which is probably how the soundcard is doing the filtering), and invert both the amplitude and phase response from that.
Some of the previous answers have correctly noted that it is the high-pass filter (AC coupling capacitor on the soundcard's output) is what is preventing the low frequency square waves from "staying on" so they decay quickly.
There is no way to completely beat this filter from software or it wouldn't be there, now would it? If you can live with lower amplitude square waves at the lower frequencies, you can approximate them by sending out something like a triangle wave. From a transient analysis perspective, the theory of operation here is that as the coupling capacitor is discharging (blocking DC) you are increasing its bias voltage to counteract that discharge thus maintaining the square wave's plateau for a while. Of course you eventually run out of PCM headroom (you can't keep increasing the voltage indefinitely), so a 24-bit card is better in this respect than a 16-bit one as it will give you more resolution. Another, more abstract way to think of this is that the RC filter works as a differentiator, so in order to get the flat peaks of the square wave you need to give it the flat slopes of the triangle wave at the input. But this is an idealized behavior.
As quick proof of concept, here's what a 60Hz ±1V triangle signal becomes when passing through a 1uF coupling cap on a 1Kohm load; it approximates a ±200mV square wave
Note that the impedance/resistance of the load matters quite a bit here; if you lower it to, say, 100ohm the output amplitude decrease dramatically. This is how the coupling caps block DC on speakers/headphone because these devices have much lower impedance than 1Kohm.
If I can find a bit more time later today, I'll add a better simulation, with a better shaped stimulus instead of the simple triangle wave, but I can't get that from your average web-based circuit simulator software...
Well, if you're lucky you can get one of those $0.99 USB sound cards where the manufacturer has cut corners so much that they didn't install coupling caps. https://www.youtube.com/watch?v=4GNRzwfP7RE
Unfourtunately, you cannot get a good approximation of a square wave. Sound hardware is intentionally slew rate limited and would not be able to produce a falling or rising edge beyond its intended frequency range.
You can approximate a badly deformed square wave by alternating a high and low PCM code (+max, -max) every N samples.
You can't actually produce a true square wave, because it has infinite bandwidth. You can produce a reasonable approximation of a square wave though, at frequencies between say 10 Hz and 1 kHz (below 10 Hz you may have problems with the analogue part of your sound card etc, and above around 1 kHz the approximation will become increasingly inaccurate, since you can only reproduce a relatively small number of harmonics).
Tp generate the waveform the sample values will just alternate between +/- some value, e.g. full scale, which would be -32767 and +32767 for a 16 bit PCM stream. The frequency will be determined by the period of these samples. E.g. for a 44.1 kHz sample rate, if you have say 100 samples of -32767 and then 100 samples of +32767, i.e. period = 200 samples, then the fundamental frequency of your square wave will be 44.1 kHz / 200 = 220 Hz.
I found an application that I build on it.
http://www.blogger.com/blogger.g?blogID=999906212197085612#editor/target=post;postID=7722571737880350755
you can generate the format you want and even the pattern you need.
The code uses SLIMDX.