Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bumber]

I was researching this before, and, basically, no. Most things that eat mosquitos will eat whatever, and often only eat mosquitos themselves incidentally, because apparently they're not numerous enough in relation to their size.

Looks like the main predators of mosquito larvae are mosquito fish and dragonfly nymphs. Both are able to consume other insect larvae.

Also:

Dragonflies see faster than we do; they see around 200 images per second.

Dragonflies can benefit from 200 FPS monitors!

[methylatedspirit]

I dunno why, but playing Eurobeat (and other suitably-fast music) while benchmarking makes it more exciting, even if all I'm staring at is a progress bar or a terminal. Something about it makes the wait more bearable. It leads to disappointment 9 times out of 10, but I'd much prefer excitement-to-disappointment than boredom-to-disappointment.

[feelotraveller]

Fast music increases heart rate, respiration and blood pressure.  The boredom of benchmarking lets you notice it.

[dragdeler]

-

[methylatedspirit]

I've finished part of my current benchmarking (x264, x265, VP8 encoding, with various compiler optimizations), and my current summary is: pretty much the quintessential Gentoo experience. Wait for the better part of a day compiling with aggressive optimizations, get 1.5% (at best!) speed gains. Describing the speed gains as "minor" would be an overstatement. This is the computing equivalent of ricing the fuck out of a car. I don't have faith that the later phases will be much better.

[McTraveller]

Unless you can find a way to change the algorithmic complexity of what you are doing, or change it from single- to multi-thread, compiler optimizations really are likely to give you only small percentage improvements.

Also if your programs break due to aggressive optimization, there really can be compiler bugs. This is a huge issue with compilers for embedded code; my company has had several compiler patches from our vendors related to optimization bugs.

That said, there are a fair number of application-level bugs that optimization can uncover, such as hidden assumptions about sequence of operation.  Often these are related to (non-)volatility of variables, especially those subject to side effects.

[methylatedspirit]

It's recently been brought to my attention that a C64 can simulate an organ quite well, given equipment to allow for the whole reverb thing. This led me to research how organs work, and I realized that pipe organs are an early form of sine wave (P)SG. A single pipe can only produce a sine tone of some frequency determined by its length. The reverb is what gives pipe organs their distinctive sound.

Earlier still in sine-wave synths would be whistling, but that's generally less controllable, and frequency range is generally poor. I can only do 900 Hz to 1800 Hz, just 1 octave.

[McTraveller]

The reverb is what gives pipe organs their distinctive sound.

Do you mean overtones (and possibly undertones), not reverb?  Reverb is (mostly) going to come from the building in which the organ sits*; there's much academic debate about if the building - especially for large pipe organs - is part of the organ itself (since if you moved the pipes and equipment to another location, it would not sound the same at all).

*There is a bit of resonance set up in the long pipes themselves which will contribute to the sound, but it's unclear if that is what you mean, especially given the sound pressure levels involved with organs. If you could get away with it, the trick would be to hit a pipe with a mallet and hear what it sounds like - but I don't know that you'd excite those modes with the airflow itself because I think the air-based sounds are not close to the same "bell" frequency of the metal itself. But maybe by coincidence they really are close to the same, I'm curious now...

[methylatedspirit]

Shows what I know, then. I should find samples of organs playing a single note, then look at its FFT or something. That should show something. But aren't the over/undertones because almost all organ music is polyphonic? If my understanding of the theory is correct (probably not), then it should be the case that polyphony allows for overtones. A monophonic organ doesn't have overtones in that case.

Then again, they've probably produced organs that produce other, non-sine tones from a single pipe (hence, overtones) by now, so I could well be a victim of my limited knowledge. I'm assuming that organs only produce sound via resonance, for instance.

Edit: hold up, it's multiple harmonics, going {n, 3n, 5n,...} and {2n, 4n, 6n...}? This is getting awfully close to the Fourier series for one of the basic waves. Not sure which one, but it's definitely a resemblance.

I think the air-based sounds are not close to the same "bell" frequency of the metal itself. But maybe by coincidence they really are close to the same, I'm curious now...

Hmm... someone with access to an organ and a spectrum analyzer (or phone-acting-as-spectrum-analyzer) could test that, right? Now, as for where I can find an organ, that's gonna be hard. There aren't many churches where I live, and I doubt they have the budget to buy such large organs.

[feelotraveller]

Damn, now you've got me downloading Tubular Bells all over again.

[methylatedspirit]

This is gonna be a bullshit think, but:

Fraunhofer provides an AAC codec library called libfdk_aac, and a speed-optimized version is used for Android devices. It's the standard AAC codec in Android, AFAIK. In FFmpeg's wiki, there's an encoding guide for AAC, and it states the following:

Note: libfdk_aac defaults to a low-pass filter of around 14kHz (​details). If you want to preserve higher frequencies, use -cutoff 18000. Adjust the number to the upper frequency limit only if you need to; keeping in mind that a higher limit may audibly reduce the overall quality.

Pretty shit cutoff frequency, honestly. Just 14 KHz? I can hear up to 18, and I do notice a bit of loss in noise-like instruments at just 14 KHz.

The conspiracy starts when I realized that both iOS and Android phones are capable of using AAC as a codec for Bluetooth audio. They use libfdk_aac, so the cutoff would be by default 14 KHz, and it may be adjusted upwards depending on the manufacturer. I've used this passage before, but it's relevant:

The Huawei P20 Pro performs the worst, with a roll-off occurring at an stunningly-low 14.2kHz—very much still with the range of most people’s hearing. The LG V30 performs marginally better by rolling off at 16kHz, followed by the Samsung Galaxy Note 8 at 17kHz. The iPhone 7 performed by far the best, extending its limit up to 18.9kHz. Although Apple’s phone begins a slower roll-off that has a -3dB point set at about 18kHz.

The lowest cutoff frequency is held by the Huawei at just ~14 KHz, just like the default cutoff for libfdk_aac. Suspiciously similar. Assuming Huawei are using libfdk_aac (I see no reason why not), this implies that Huawei are a bunch of dumb-dumbs and forgot to adjust the cutoff to something higher.

It seems that no-one can agree on a good cutoff value, either; LG uses 16 KHz, Samsung 17, and Apple 18.9. Seems like LG and Samsung are afraid of quality losses from a higher cutoff, so they went for more conservative values. Standardization, my ass!

[dragdeler]

-

[Bumber]

They're kings, not warriors. Duh.

[scriver]

When all heroes lie dead the kings live on - Laleh (paraphrasetranslated)

[methylatedspirit]

So I created this dumb diagram to illustrate a point. I apologize to all the pixel artists out there; I don't think it's very good.


Yeah, when I did that thing where I told FFmpeg to interpret image data as a raw video, push it it through video codecs, then decode it back to get the final result, this is quite literally what I meant. Of course, the resolutions used are a bit higher. I'm realizing that the resolution used for the intermediate "video" has quite a lot of bearing on the pattern of the distortion caused by this lossy encoding.

In this one, the intermediate video was 100x150. (The original image was 2000x3000; cropped for file size reasons).

.

Very strong, predictable horizontal blocking pattern. I'd call that macro-macroblocking.

Here's one where it was 149x211; both prime numbers (don't believe me? The OEIS says as much)



Less predictable. It's noisier, but part of me still thinks there's some pattern to it. It's going from top-left to bottom-right.

Prime numbers can yield a discernible pattern, then. I'm wondering if there exists integers a and b, both equal to or greater than 128 (to keep the codecs happy), such that when used as input dimensions for this process, they produce the "noisiest" pattern.

This feels like a distant relative of the "optimal sunflower seed arrangement" problem, but I'm not sure why I'm saying that. There, it's concerned with packing the most seeds per area. Here, I'm trying to find the input values that yield the least "predictable" patterns.

There does exist the least elegant, brute-force method; just iterate over a and b between 128 and their respective maxima. I already know how that goes in Python:

Code: [Select]

for a in range(128, 2000):
    for b in range(128, 3000):
        inSize = str(a) + "x" + str(b)
which would be some 5 million possible resolutions and output images. Not feasible. Even if I limited the range to [128, 500], it'd still be a staggering 130 thousand.

I dunno, modular arithmetic? You want to find a and b such that a*b*x mod 2000 (x is the "frame number", 2000 is the image width) yields the longest possible period? But that's not even the case; f(x) = 149*211x mod 2000 still generates a 2000-long period (which is the longest possible?), yet produces a visible pattern of some kind. Maybe if you consider the simplest possible "encoder"? Odd frames black, even frames white?

I have no clue anymore.