>Question is, will it matter by then? I guess only >time will tell.
Of course. People will still be encoding video in 3 years. Tarkin technology is angled more towards future development than most formats nowadays which are all more or less based on the level of technology MPEG4 is based on. That doesn't mean it's the last word.
For example, 3 years ago we had MP3. That didn't cause Vorbis 'not to matter'. It is better technology. It is free.
Tarkin is currently working on bringing new technologies such as wavelets and 3-d transforms into video coding. It's not finished yet, but it offers more possibilities for really new technology and further development.
While this is great news, it by no means means that Ogg Tarkin suddenly is obsoleted:) VP3 is available now though, and Tarkin isn't.
>With XVID video and OGG sound all in a OGM file >(OGg Media) i get fully legal DVD-Rip !!!:)
That's assuming XviD doesn't rely on any external MPEG4 patents, and as far as I know, it does.
It's in a similar situation as LAME. The code is GPL, but not legal to use in most countries due to patents. This is why the binaries are usually found on a Russian or Brazialian server.
Distributed.net has gotten to be a more or less pointless project by now.
Originally, the point they wanted to make was that 64-bit RC5 was not strong enough to protect privacy.
They started, what, 4-5 years ago? About 30 000 computers running for 4 years can't break 64-bit encryption. Geez, I'd say that, if anything, the conclusion would be that 64-bits is plenty for shopping etc. unless you've got some really _big_ secrets. Certainly plenty for day-to-day mail. More or less the opposite of what they wanted to prove.
Nowadays they've added the OGR stuff to appear at least a bit more usefull, but in reality, the applications of those results are very limited.
Really, the right thing to do is not to waste power on such pointless projects.
>Wait, I don't understand that. Is this good or bad? >Resistant meaning that you couldn't use DES for this >type of new and better cryptography or the opposite >that the DES was made stronger by the NSA changes... >I'm confused.
It was made stronger. Differential cryptanalysis is a technique to break ciphers. It's applicable to DES, but just barely, and is not really pratical. However, most DES variants made by people who didn't like using the NSA-modified DES could be broken very easily, because they did not know of the attack and consequently didn't defend against it.
>The major thing holding back OGG/Vorbis right
>now is that WinAmp doesn't support it by
>default, but that will change with WinAmp v3...
It's already in the update pack for Winamp v2.
http://www.blorp.com/~peter/zips/wa2update.exe
(or seperately)
http://www.blorp.com/~peter/zips/in_vorbis.exe
From what I've heard, the reason that it isn't included by default yet is that AOL has lawyers trying to figure out if it is legally 999% safe for them to include it. Reasonable precaution thinking about what a lawysuit with Thompson would cost them. Seems that all is fine considering Vorbis is included in the update pack. Should shut up those people who keep saying 'vorbis 'll get sued' too.
At least one Winamp developer has become a Vorbis fanatic, so I can't imagine it taking long before the plugin will be included by default.
The number of people complaining about Ogg having quality problems on Slashdot (without clips or objective blind testing) is inversely proportional to the number of people actually posting clips/blind test results to the Ogg Vorbis mailinglists.
Funny, most people we've spoken to vastly preferred Ogg over WMA. I guess that you are an exception - at that bitrate, both codecs will artifact and it's very much personal what one prefers.
Low-bitrate tuning is on the todo-list for RC4, so I suppose it'll only be getting better in any case.
All encoders use the same vorbis libs, so as long as they use the lastest RC3 libs you're fine. Just get oggenc or oggdrop off the vorbis.com site.
_Always_ use -q when encoding, don't use bitrate settings. Start with -q0 and go up (-q1, -q2,...) till you don't hear the difference any more.
BTW. --r3mix has been pretty much superseded in LAME by --alt-preset standard. Much better quality with very minor increase in bitrate. It's amazing an MP3 encoder can work as good as that settings does.
>I think the idea of doing a double-blind test is
>great. But it should also measure performance at
>128 kbit/s as well as at higher rates. And until
>you can put some substance behind your
>pretentious claims, please refrain from posting.
Been there, done that. See http://ff123.net
Guess who came out on top. Ooh. Big suprise there eh?
>Seems the show stopper is a lag of cheap
>floating DSP hardware, that can decode ogg (mp3
>can be decoded by integer).
A hardware player is coming from iRiver. You don't need floating point hardware for Ogg either, it's just that that is what the standard libs use now. Nothing stops you from writing a fixed-point/integer version.
>I stopped seeing "Stomping on Athlon bug" (the
>classic VIA chipset problem)
IIRC the 'Athlon bug stomper' is not the classic VIA chipset problem (which are the KT133A/686B's from hell)
It's related to a BIOS setting some MB manufacturers use to increase performance on the Athlon. AMD had specifically indicated the setting as 'reserved - do not change' but some did anyway, causing Athlon optimized Linux kernels to crash because they are overfloring an internal buffer (memory write queue). It can happen in Windows too with optimized video drivers. Newer Linux kernels detect and reset the setting to a stable value.
>Why place all the blame on AMD? If you write
>pentium-optimized code, what's so surprising if it
>won't work exactly right on an AMD?
It's not _nothing_ _whatsoever_ to do with Pentium optimized code. It's a new feature that both Intel and AMD cpu's support. Or in AMD's case, are supposed to support.
Good point. The reason is simply because alpha-beta is relatively simple and works so damn well.
It's not very nice to spend hours and hours developing something new and seeing it get torn apart in the next tournament by much simpler things. There was only one attempt that was moderatrely successfull that I know of, and that was UlyssesCNS, using Parallel Controlled Conspiracy Number Search.
>Go has a high branching factor due to the >enormous board size but branches also get pruned >a lot faster because there are extensive >libraries of patterns known to be bad. Scoring a >chess position is not as exact.
It's way, waaay harder to score a Go position.
In chess, count the material and you'll already have a good idea who's winning in 95% of the positions a _computer_ looks at. There is no such equivalent for go.
>For example, he never got to view any of Deep
>Blue's previous games -- whereas in a human
>match, any world class grandmaster would
>certainly have studied his opponents games >before hand as preparation.
They barely got the machine assembled and tested before the match. He got no games simply because there weren't any yet!
>Secondly, Kasparov didn't actually play the same >program through the whole match -- the program >was tweaked as the match went along.
Can you imagine telling Kasparov he's not allowed to learn anything from the previous game? It's not because he learns that he becomes a different man.
The situation in the Kramnik-Fritz match is just as bad. They aren't even allowed to fix bugs in the program. Is _that_ fair?
>I'm surprised no one is using a cluster though. >With hardware prices so cheap, a 6 node cluster >can be built for less than $1500. I am doing >that right now in fact.
The latency of a (standard) cluster is too high to make it effective for chessprogramming. Moreover, it doesn't have shared memory, which is another major disadvantage.
There has been a project to make programs run over a cluser (APHID, find it via google), but as you've already seen it didn't leave a terribly good impression.
>The S-tables were thought to have been chosen to
>make the algorithm easy to break for someone who
>knew the secret.
Yes, this is what was _thought_.
When differential cryptanalysis was discovered in 1991, many DES 'replacements' were completely broken, but DES itself was only weakened, not broken.
It turned out to be those NSA-picked S-boxes that made it much more secure than the alternatives. So, they actualy made the algorithm stronger, not weaker.
(and they had appearently knew about differential cryptanalysis some 20 years before the academic world did. scary, isn't it?)
>I started RipperX, choosed to encode the first
>track using the highest setting (320k), High
>Quality mode, no CRC, no VBR and ran the encoding.
You failed indeed. Ogg has no 320kbps mode (It has a 350kbps, whereas it's MP3 that has a 320kbps mode), nor does it have any kind of 'high-quality' switch, and _all_ modes are VBR right now.
I have no idea what you did, but whatever came out of it sure wasn't ogg-related:-/
Slashdot Mirror
>Question is, will it matter by then? I guess only
>time will tell.
Of course. People will still be encoding video in 3 years. Tarkin technology is angled more towards future development than most formats nowadays which are all more or less based on the level of technology MPEG4 is based on. That doesn't mean it's the last word.
For example, 3 years ago we had MP3. That didn't cause Vorbis 'not to matter'. It is better technology. It is free.
--
GCP
Tarkin is currently working on bringing new technologies such as wavelets and 3-d transforms into video coding. It's not finished yet, but it offers more possibilities for really new technology and further development.
While this is great news, it by no means means that Ogg Tarkin suddenly is obsoleted
--
GCP
>With XVID video and OGG sound all in a OGM file :)
>(OGg Media) i get fully legal DVD-Rip !!!
That's assuming XviD doesn't rely on any external MPEG4 patents, and as far as I know, it does.
It's in a similar situation as LAME. The code is GPL, but not legal to use in most countries due to patents. This is why the binaries are usually found on a Russian or Brazialian server.
--
GCP
Distributed.net has gotten to be a more or less pointless project by now.
Originally, the point they wanted to make was that 64-bit RC5 was not strong enough to protect privacy.
They started, what, 4-5 years ago? About 30 000 computers running for 4 years can't break 64-bit encryption. Geez, I'd say that, if anything, the conclusion would be that 64-bits is plenty for shopping etc. unless you've got some really _big_ secrets. Certainly plenty for day-to-day mail. More or less the opposite of what they wanted to prove.
Nowadays they've added the OGR stuff to appear at least a bit more usefull, but in reality, the applications of those results are very limited.
Really, the right thing to do is not to waste power on such pointless projects.
--
GCP (Moderation suggestion: -1 Disagree)
We've had this one before. Where's the 'new' in news?
--
GCP
>Wait, I don't understand that. Is this good or bad?
>Resistant meaning that you couldn't use DES for this
>type of new and better cryptography or the opposite
>that the DES was made stronger by the NSA changes...
>I'm confused.
It was made stronger. Differential cryptanalysis is a technique to break ciphers. It's applicable to DES, but just barely, and is not really pratical. However, most DES variants made by people who didn't like using the NSA-modified DES could be broken very easily, because they did not know of the attack and consequently didn't defend against it.
--
GCP
>The major thing holding back OGG/Vorbis right
>now is that WinAmp doesn't support it by
>default, but that will change with WinAmp v3...
It's already in the update pack for Winamp v2.
http://www.blorp.com/~peter/zips/wa2update.exe
(or seperately)
http://www.blorp.com/~peter/zips/in_vorbis.exe
From what I've heard, the reason that it isn't included by default yet is that AOL has lawyers trying to figure out if it is legally 999% safe for them to include it. Reasonable precaution thinking about what a lawysuit with Thompson would cost them. Seems that all is fine considering Vorbis is included in the update pack. Should shut up those people who keep saying 'vorbis 'll get sued' too.
At least one Winamp developer has become a Vorbis fanatic, so I can't imagine it taking long before the plugin will be included by default.
--
GCP
The number of people complaining about Ogg having quality problems on Slashdot (without clips or objective blind testing) is inversely proportional to the number of people actually posting clips/blind test results to the Ogg Vorbis mailinglists.
We can't fix problems that don't exist.
--
GCP
Funny, most people we've spoken to vastly preferred Ogg over WMA. I guess that you are an exception - at that bitrate, both codecs will artifact and it's very much personal what one prefers.
Low-bitrate tuning is on the todo-list for RC4, so I suppose it'll only be getting better in any case.
--
GCP
>What encoder to use? What options to use?
...) till you don't hear the difference any more.
All encoders use the same vorbis libs, so as long as they use the lastest RC3 libs you're fine. Just get oggenc or oggdrop off the vorbis.com site.
_Always_ use -q when encoding, don't use bitrate settings. Start with -q0 and go up (-q1, -q2,
BTW. --r3mix has been pretty much superseded in LAME by --alt-preset standard. Much better quality with very minor increase in bitrate. It's amazing an MP3 encoder can work as good as that settings does.
--
GCP
>I think the idea of doing a double-blind test is
>great. But it should also measure performance at
>128 kbit/s as well as at higher rates. And until
>you can put some substance behind your
>pretentious claims, please refrain from posting.
Been there, done that. See http://ff123.net
Guess who came out on top. Ooh. Big suprise there eh?
--
GCP
Nice troll.
Of course you reported those problmatic clips to us Vorbis developers so we could fix those problems, didn't you?
Oh, you didn't? I can guess why. They don't exist. I'd love to see clips where MP3 outperforms RC3 at the same bitrate. Really.
--
GCP
>Seems the show stopper is a lag of cheap
>floating DSP hardware, that can decode ogg (mp3
>can be decoded by integer).
A hardware player is coming from iRiver. You don't need floating point hardware for Ogg either, it's just that that is what the standard libs use now. Nothing stops you from writing a fixed-point/integer version.
--
GCP
>Even lame [sulaco.org] supports ogg coding
>through libogg.
LAME doens't support Ogg coding - the code is way outdated and doesn't cope with the newest vorbis libs.
--
GCP
>I stopped seeing "Stomping on Athlon bug" (the
>classic VIA chipset problem)
IIRC the 'Athlon bug stomper' is not the classic VIA chipset problem (which are the KT133A/686B's from hell)
It's related to a BIOS setting some MB manufacturers use to increase performance on the Athlon. AMD had specifically indicated the setting as 'reserved - do not change' but some did anyway, causing Athlon optimized Linux kernels to crash because they are overfloring an internal buffer (memory write queue). It can happen in Windows too with optimized video drivers. Newer Linux kernels detect and reset the setting to a stable value.
--
GCP
>Why place all the blame on AMD? If you write
>pentium-optimized code, what's so surprising if it
>won't work exactly right on an AMD?
It's not _nothing_ _whatsoever_ to do with Pentium optimized code. It's a new feature that both Intel and AMD cpu's support. Or in AMD's case, are supposed to support.
--
GCP
>If the player has to use only memory for
>openings, so should the computer.
Where do you think they store it?
A harddisk is essentially external memory.
--
GCP
Good point. The reason is simply because alpha-beta is relatively simple and works so damn well.
It's not very nice to spend hours and hours developing something new and seeing it get torn apart in the next tournament by much simpler things. There was only one attempt that was moderatrely successfull that I know of, and that was UlyssesCNS, using Parallel Controlled Conspiracy Number Search.
--
GCP
>Go has a high branching factor due to the >enormous board size but branches also get pruned >a lot faster because there are extensive >libraries of patterns known to be bad. Scoring a >chess position is not as exact.
It's way, waaay harder to score a Go position.
In chess, count the material and you'll already have a good idea who's winning in 95% of the positions a _computer_ looks at. There is no such equivalent for go.
--
GCP
>For example, he never got to view any of Deep
>Blue's previous games -- whereas in a human
>match, any world class grandmaster would
>certainly have studied his opponents games >before hand as preparation.
They barely got the machine assembled and tested before the match. He got no games simply because there weren't any yet!
>Secondly, Kasparov didn't actually play the same >program through the whole match -- the program >was tweaked as the match went along.
Can you imagine telling Kasparov he's not allowed to learn anything from the previous game? It's not because he learns that he becomes a different man.
The situation in the Kramnik-Fritz match is just as bad. They aren't even allowed to fix bugs in the program. Is _that_ fair?
--
GCP
>While I agree that this is strictly true, the >hardware used does not vary dramatically -- most >every one is a 1 GHz - 2 GHz machine.
Considering that a doubling of speed is often said to equal about 50-70 elo points, the difference certainly _does_ matter.
Many of the programs are very close in playing strength. A free 50-70 ELO boost can make quite a difference in where you finish eventually.
--
GCP
>I'm surprised no one is using a cluster though. >With hardware prices so cheap, a 6 node cluster >can be built for less than $1500. I am doing >that right now in fact.
The latency of a (standard) cluster is too high to make it effective for chessprogramming. Moreover, it doesn't have shared memory, which is another major disadvantage.
There has been a project to make programs run over a cluser (APHID, find it via google), but as you've already seen it didn't leave a terribly good impression.
--
GCP
>The S-tables were thought to have been chosen to
>make the algorithm easy to break for someone who
>knew the secret.
Yes, this is what was _thought_.
When differential cryptanalysis was discovered in 1991, many DES 'replacements' were completely broken, but DES itself was only weakened, not broken.
It turned out to be those NSA-picked S-boxes that made it much more secure than the alternatives. So, they actualy made the algorithm stronger, not weaker.
(and they had appearently knew about differential cryptanalysis some 20 years before the academic world did. scary, isn't it?)
--
GCP
Or just run patch with the -l option
patch -p1 -l virofix
--
GCP
>I started RipperX, choosed to encode the first
:-/
>track using the highest setting (320k), High
>Quality mode, no CRC, no VBR and ran the encoding.
You failed indeed. Ogg has no 320kbps mode (It has a 350kbps, whereas it's MP3 that has a 320kbps mode), nor does it have any kind of 'high-quality' switch, and _all_ modes are VBR right now.
I have no idea what you did, but whatever came out of it sure wasn't ogg-related
--
GCP