Idea One:

We know that mono files are 50% smaller. But these files are... only mono ;) Audio players can generate quasi-stereo from mono files. There is many methods including playing some frequencies in left channel and other in the another one and playing one channel delayed by XXX miliseconds. It`s good only for streaming, not for audiobackup.

Idea Two:

Downloading audio files from internet cause risk of having files that are not downloaded completly (vide Napster). How about adding CRC32 (like SFV one) to OGG file for checking file integrity? BUT(!), for almost whole file, not for each frame. But... writing CRC will change CRC of file ;) So, CRC for whole file, but not for Tagging header.

File Structure:
1)---------------- - some data from beginning of file
2)Txt information like serial, album name, verision of vorbis etc. INCLUDING CRC
3)---------------- - rest of file

CRC will be for 1) and 3) only, written in 2) so changing tags will not disrupt CRC.

I don't know exactly what you mean by that, but in each Ogg Logical Bitstream there is already a 32-bit CRC check that is computed over the entire header and the page that looks for any checksum mismatches drop's sync and looks for recapture, is that what you are referring to?.

Ogg Bistream Framing Description:

Hmm, additional CRC32/MD5 info should be:
1) Easy to acces
2) Only ONE (max two) per file (more CRC`s=more CPU power to check)
3) For whole file exept the part of file, that user can change by tagging - not for whole file!!!

What for?

It`s not for streaming... but for good ftp servers, clients and other file sharnig programs. These programs can check CRC32/MD5 of file, so damaged files will not be ditributed over internet and these programs does not need to make eg. *.SVF files for OGG files. Changing tag will not disrupt CRC32, so file sharing programs can indentify files after some (maybe cosmetic) changes made na tag by users.
Maybe use md5? The md5 number will be more unique than CRC32 (in future there will be maaaaaany ogg files over internet - md5 can act both as serial number and integrity checker like CRC32).

I think it will be unique technology.

I never really took that into consideration. I could be mistaken, but I "thought" next to the 32-Bit CRC provided in the framing spec, Ogg Vorbis would provide no other additional error correction or checking as that would be left up to whoever was designing the application another Developer say, I could be wrong though.

The only advantage MD5 has over CRC32 is that it is cryptographically secure. That is, it will protect you if someone intentionally tries to create files with identical checksums. But that is no threat.

Combine this with the serial number, and you have a check that will not suffer from collisions.

This is something that you should do with a player plugin. It has nothing to do with the format.

I was going to mention that I wasn't sure if that had anything to do with the topic though.

FYI :

MCF files will have unique MD5 identifiers in the header ( not being calculated over whole file, but block headers AFAIK ) , for distribution over internet and MCF multiple segment files ....

So Peter Pawlowski should read this (i use Winamp).

So file sharing programs can easily check build-in crc of *.ogg files and tagging will not change crc?

I think it IS a threat - record companies are already fighting gnutella by intentionally distributing mp3s of major upcoming releases in fucked up form - silent, 30 seconds looped, etc, making it harder to find the real leaked version. It wouldnt surprise me at all if (assuming such an integrity check were added to a major audio format) they tried to fake the CRC's of their bogus tracks to match the real ones.

How will this help you? You'd need to know the MD5's of the faked records and the ones of the true records to make the determination. If you can make sure you get an authentic MD5, you could also have made sure you got an authentic file. You don't gain anything here.

Moreover, it's not because constructing two files with identical CRC32's is *theoretically* easier than with an MD5 that it is actually easy and that someone will care to do so.

Remember that the CRC is there for integrity checking. It's not there for authentication. If you want authentication, you need to design a system around that, not add it as an afterthought.

Also, it's not Vorbis idea to cater to music pirates and make it harder for legitimate copyright holders to enfore their property. Certainly not.

So in short, using MD5 over CRC32 doesn't gain you anything as far as integrity checking is concerned, and it doesn't gain you anything in authenticating either. It's no use.

A third party can do it as well. I personally would never use something that f*cks up the sound like this, but hey, don't let that stop you

You can't ever be sure.

Then, why don't you go with 5-passes 256 bit HAVAL hashes?
Or maybe even 512 bit SHA hashes?

CRC32 has the advantage of being able to fix bit errors in the transmission.

I am not sure if you can use crc32 to correct errors.
To my mind it is only an error detector.

You are talking about idea 1? It will be as option in players (user can switch on/off).