I guess my point was that consuming bandwidth to stream white noise from a phone that’s on for other reasons is a rather efficient use of resources. My assumption was that using running water wouldn’t be the retort because A) it’s more valuable than electricity & B) there’s a pump involved somewhere in the process. I assumed wrong, but we played the game & no harm was done.
You could have water run out of one bucket into another. Just swap the buckets when the upper one is empty. It functions as a clock also if you keep track of how many times you swap the buckets.
Compression algorithms generally rely on sensing patterns in the data to allow you to store just one example of that data and where it repeats, instead of storing it all fully. This is extremely visible in H264 and H265 for video, where the first is easily 1% the size of the raw video data, and the second is easily 1/10th the size of that, since it can detect more patterns to compress.
White noise means your mp3 is basically the size of the uncompressed data, instead of being 5-25% that size (stat from Wikipedia on compression ratio of mp3). This costs Spotify more for storage and streaming bandwidth.
The paychoacoustic models just do their best for the given Bitstream and it’s not true white noise, just the most audible parts, you end up with the lowest 30 Harmonics or so that it can find (random numbers have a lot of harmonics.
White noise means your mp3 is basically the size of the uncompressed data
You’re forgetting that mp3 is a very lossy compression algorithm that’ll happily discard much of the frequency spectrum, which in the case of white noise actually would be a pretty significant amount of data.
It costs fractions of pennies to transfer data across the internet, especially something as small as a white noise audio file.
Famously compressible white noise.
If only there was a way to locally generate white noise in real time, but alas…
Do you know a good way to do it w/o electricity?
Running water from a faucet with an aerator
I love the malicious compliance of this
I guess my point was that consuming bandwidth to stream white noise from a phone that’s on for other reasons is a rather efficient use of resources. My assumption was that using running water wouldn’t be the retort because A) it’s more valuable than electricity & B) there’s a pump involved somewhere in the process. I assumed wrong, but we played the game & no harm was done.
You could have water run out of one bucket into another. Just swap the buckets when the upper one is empty. It functions as a clock also if you keep track of how many times you swap the buckets.
Hot water, obviously.
deleted by creator
Maybe a pegboard with tens of thousands of tuning forks on it?
deleted by creator
Light a campfire in your bedroom
Audio size is based on the quality of the recording, not what the recording is.
If the white noise is for some reason recorded in high quality, it’s going to use as much data as music.
Compression algorithms generally rely on sensing patterns in the data to allow you to store just one example of that data and where it repeats, instead of storing it all fully. This is extremely visible in H264 and H265 for video, where the first is easily 1% the size of the raw video data, and the second is easily 1/10th the size of that, since it can detect more patterns to compress.
White noise means your mp3 is basically the size of the uncompressed data, instead of being 5-25% that size (stat from Wikipedia on compression ratio of mp3). This costs Spotify more for storage and streaming bandwidth.
It really doesn’t, not at all.
The paychoacoustic models just do their best for the given Bitstream and it’s not true white noise, just the most audible parts, you end up with the lowest 30 Harmonics or so that it can find (random numbers have a lot of harmonics.
Brain can’t tell, brain is dumb.
You’re forgetting that mp3 is a very lossy compression algorithm that’ll happily discard much of the frequency spectrum, which in the case of white noise actually would be a pretty significant amount of data.
That’s only true for constant rate compression, not for variable bitrate compression