Anti-matter still has a positive mass. Otherwise when a positron meets an electron it wouldn't release any energy. Personally, I highly doubt it "falls up", as that would be inconsistent with general relativity because anti-particles would not follow a curved space. What would be really cool is if it was found that anti-matter curved space in the opposite direction as matter, making gravity repulsive. I highly doubt that's the case, but it would certainly be a cool discovery.
KDevelop 3 was indeed pretty nice and I used it for a while. But then -- like too many OSS projects these days -- developers decided it'd be much better if they rewrote it. The result is that version 3 stagnated for a long time and when KDevelop 4 was finally ready, it ditched support for many features, including autoconf/automake which I used for all my projects. That's when I switched to Eclipse/CDT and I've been happy with it since then.
Modern codecs are better at 256 kb/s than MP3 is at 320 kb/s. Also, at those rates, it depends a lot on the actual encoder. The newer formats (be it Opus, Vorbis or AAC) all have the potential of giving you perfect quality at 256 kb/s VBR. In the (very) few cases where you can hear an artefact, it's due to the encoder making the wrong decision (e.g. not detecting a transient).
And try Musepack or Layer2 on something extremely tonal like harpsichord or (to a lesser extent) 12-string acoustic guitar. Each type of codecs has upsides and downsides. Overall though a freq-domain codec *with* a good encoder should be better because it still has the option of going with a good time resolution (Layer2 can't ever use a good freq resolution).
Could you please post the specs of the reel to real equipment you're using. To beat a 16-bit digital system, it has to have better than 96 dB SNR and dynamic range. I don't remember having ever seen that.
And the solution to both objections (including doctors not wanting to be obsolete) is to have the machine *assist* the doctor, in a similar way that auto-pilots assist but do not replace pilots.
I think overall for-profit companies have made a huge contribution to the Free Software community. While Canonical has probably contributed less than many others, I still still their total contribution as positive. Of course I still disagree when their new Ubuntu spyware and even before that I had already decided to stop using it for unrelated reasons (Unity and other interface-related decisions). In any community, there will be individuals and companies that do the wrong thing and I don't see anything special about for-profit. The best example of non-profit org messing up badly that comes to mind (there's probably many more) is XFree86. That was quickly worked around.
Many have commented that "people don't use $1 coins", but it's not like most people actually choose one over the other. In practice, you withdraw money as $20 bills or something like that. You only get $1 coins/bills as change when you buy something. So in practice, it's the stores and/or the banks that decide, not individual people.
The work-around is to actually download the ad and just not display it. Then the publisher gets to pay extra bandwidth for still not having their ads displayed. What I *am* surprised of is that they aren't just serving ads from the servers as the "content" to avoid detection in the first place.
You can justify fines for under-consuming. However, there's no way you can justify the fines being higher than the cost of the electricity that was not consumed, as seems to be the case here. This is silly.
We tend to use.opus for file extension, although people can use what they like. Using Ogg doesn't mean you're forced to use the.ogg extension you know.
The idea of mid-side encoding is purely for quality and compression efficiency. The idea is that human perception is (partially) mid-side and because left and right are often correlated, we can remove some redundancy to save bits. In fact, the way we do it, mid-side doesn't even make downmixing easier (like for FM), so it's purely for efficiency.
What Monty mostly regretted were some decisions that caused a large increase in the amount of *RAM* required. We were actually careful about that. Another improvement compared to Vorbis is that we don't have these codebooks that you need to carry in the headers. This means you can join an ongoing Opus stream with no signalling whatsoever.
Even then, I suspect a heavily power-optimized ARM core might be better than some custom hardware that's designed just for Opus. Keep in mind that any hardware you design will still have a fully programmable core in it, so in the end what you gain by doing more stuff in hardware you lose by not having your chip nearly as optimized as a more general-purpose CPU.
I don't think silicon support for audio codecs is really useful anymore. Audio codecs have such a low complexity compared to video that modern smartphones can run them really easily.I haven't measured exactly, but I'd say you can probably decode an Opus stream with about 2% CPU on the latest Android phone. Not worth paying for extra silicon.
there is test code, but I didn't see sample code explicitly.
Well, we have code snippets for the encoder and the decoder. Otherwise, there's always the code for opus_demo.c and opusenc.c/opusdec.c. Let me know what you think is missing and we can try improving that.
Last I checked, APT-X was not lossless (you can't be lossless and guarantee a compression ratio). Also, the only time I saw a comparison between APT-X and Opus, Opus was actually winning hands down. APT-X claims compression ratios of 4:1 (so 384 kb/s for 48 kHz stereo). Opus is already transparent long before that. I've never had anyone telling us he could hear any kind of artefact whatsoever above 200 kb/s VBR). Usually, 128 kb/s (12:1) is transparent for the vast majority of content and listeners (yes, there are a few exceptions at that rate).
Slashdot Mirror
Anti-matter still has a positive mass. Otherwise when a positron meets an electron it wouldn't release any energy. Personally, I highly doubt it "falls up", as that would be inconsistent with general relativity because anti-particles would not follow a curved space. What would be really cool is if it was found that anti-matter curved space in the opposite direction as matter, making gravity repulsive. I highly doubt that's the case, but it would certainly be a cool discovery.
KDevelop 3 was indeed pretty nice and I used it for a while. But then -- like too many OSS projects these days -- developers decided it'd be much better if they rewrote it. The result is that version 3 stagnated for a long time and when KDevelop 4 was finally ready, it ditched support for many features, including autoconf/automake which I used for all my projects. That's when I switched to Eclipse/CDT and I've been happy with it since then.
Modern codecs are better at 256 kb/s than MP3 is at 320 kb/s. Also, at those rates, it depends a lot on the actual encoder. The newer formats (be it Opus, Vorbis or AAC) all have the potential of giving you perfect quality at 256 kb/s VBR. In the (very) few cases where you can hear an artefact, it's due to the encoder making the wrong decision (e.g. not detecting a transient).
And try Musepack or Layer2 on something extremely tonal like harpsichord or (to a lesser extent) 12-string acoustic guitar. Each type of codecs has upsides and downsides. Overall though a freq-domain codec *with* a good encoder should be better because it still has the option of going with a good time resolution (Layer2 can't ever use a good freq resolution).
Could you please post the specs of the reel to real equipment you're using. To beat a 16-bit digital system, it has to have better than 96 dB SNR and dynamic range. I don't remember having ever seen that.
And the solution to both objections (including doctors not wanting to be obsolete) is to have the machine *assist* the doctor, in a similar way that auto-pilots assist but do not replace pilots.
I think overall for-profit companies have made a huge contribution to the Free Software community. While Canonical has probably contributed less than many others, I still still their total contribution as positive. Of course I still disagree when their new Ubuntu spyware and even before that I had already decided to stop using it for unrelated reasons (Unity and other interface-related decisions). In any community, there will be individuals and companies that do the wrong thing and I don't see anything special about for-profit. The best example of non-profit org messing up badly that comes to mind (there's probably many more) is XFree86. That was quickly worked around.
Many have commented that "people don't use $1 coins", but it's not like most people actually choose one over the other. In practice, you withdraw money as $20 bills or something like that. You only get $1 coins/bills as change when you buy something. So in practice, it's the stores and/or the banks that decide, not individual people.
The work-around is to actually download the ad and just not display it. Then the publisher gets to pay extra bandwidth for still not having their ads displayed. What I *am* surprised of is that they aren't just serving ads from the servers as the "content" to avoid detection in the first place.
And how do you extract the gold-extracting bacteria from the water?
You can justify fines for under-consuming. However, there's no way you can justify the fines being higher than the cost of the electricity that was not consumed, as seems to be the case here. This is silly.
According to Michio Kaku, the biggest advantage the US has is the H-1B.
Create dummy company, license entire patent portfolio for $1, law worked around. These issues are not *that* simple.
Apparently they decided to define it by sticking a large rock in orbit around the sun.
You mean this?
Yes, any hardware you design to implement something as complex as an Opus decoder will have a programmable core. Otherwise it's insane.
We tend to use .opus for file extension, although people can use what they like. Using Ogg doesn't mean you're forced to use the .ogg extension you know.
The idea of mid-side encoding is purely for quality and compression efficiency. The idea is that human perception is (partially) mid-side and because left and right are often correlated, we can remove some redundancy to save bits. In fact, the way we do it, mid-side doesn't even make downmixing easier (like for FM), so it's purely for efficiency.
What Monty mostly regretted were some decisions that caused a large increase in the amount of *RAM* required. We were actually careful about that. Another improvement compared to Vorbis is that we don't have these codebooks that you need to carry in the headers. This means you can join an ongoing Opus stream with no signalling whatsoever.
Even then, I suspect a heavily power-optimized ARM core might be better than some custom hardware that's designed just for Opus. Keep in mind that any hardware you design will still have a fully programmable core in it, so in the end what you gain by doing more stuff in hardware you lose by not having your chip nearly as optimized as a more general-purpose CPU.
Actually, the "AAC" curve in the graph is meant to represent the best of AAC-LC and HE-AAC at a given rate. I agree that wasn't obviousl
I don't think silicon support for audio codecs is really useful anymore. Audio codecs have such a low complexity compared to video that modern smartphones can run them really easily.I haven't measured exactly, but I'd say you can probably decode an Opus stream with about 2% CPU on the latest Android phone. Not worth paying for extra silicon.
there is test code, but I didn't see sample code explicitly.
Well, we have code snippets for the encoder and the decoder. Otherwise, there's always the code for opus_demo.c and opusenc.c/opusdec.c. Let me know what you think is missing and we can try improving that.
Haha! I've actually had that sig for about a year now.
Last I checked, APT-X was not lossless (you can't be lossless and guarantee a compression ratio). Also, the only time I saw a comparison between APT-X and Opus, Opus was actually winning hands down. APT-X claims compression ratios of 4:1 (so 384 kb/s for 48 kHz stereo). Opus is already transparent long before that. I've never had anyone telling us he could hear any kind of artefact whatsoever above 200 kb/s VBR). Usually, 128 kb/s (12:1) is transparent for the vast majority of content and listeners (yes, there are a few exceptions at that rate).