Slashdot Mirror
Bitrate Peeling with Ogg Vorbis
Yort writes "Thought this might be interesting to some audiophile /.ers - there's been some discussion on the Ogg Vorbis lists, summarized in the most recent Ogg Traffic, about "bitrate peeling". In short, it's where you can simply "peel off" the high resolution data from the ends of an audio stream packet to come up with a smaller, lower quality stream. Brings up a number of geek-cool opportunities."
That may be true if it were peeling off the copyright instead of the bitrate.
Though it does sound like a pretty cool way to downsample a stream.
-hero.
I don't know of any that play Vorbis files yet, but it would be very handy if I could take an OGG I had encoded at a high bitrate (for playback on my nice home stereo) and make it smaller for use on a walkman-type player for the gym or whatever.
Bitrate peeling is a briliant idea, and would be a major win for Vorbis if they ever actually provide an implementation of it. It's something that the format supposedly supports, but right now it's still just a hypothetical application.
Let me know when they've got something working THEN I'll be impressed
my sig's at the bottom of the page.
Lately I've been finding all I can download off P2P programs like Direct Connect and Furthurnet. Its mostly live shows, and they are all in .shn format, which is a lossless compression format that restores to the original .wav file.
These communities shun both compressed files like .mp3 and trading anything that has been released commercially. What you do get is great recordings of live music from bands like U2, DMB, Grateful Dead, etc., all ethically traded and in their full audio glory.
The audiophiles I know pretty much don't listen to mp3, ever.
No, Thursday's out. How about never - is never good for you?
I always kind of felt the first and third bit of every byte were kind of unnecessary. I'm not to fond of the F6 key either!
I don't think that's how it works.. from what I understand, it simply removes bits... ie:
I = one bit
----A 128k stream----
IIIIIIIIIIIIIIIIIIIIIII
----A 96k stream-----
IIII IIII IIII IIII IIII
It simply removes some of the bits, not any specific freqency of the high/low/mid.
and it looks to be an impressive streaming method
"Beni Cherniavsky mentioned a very intriguing counterpart to bitrate peeling. If you have a peeler that saves the bits it chopped off, you could reconstitute the higher quality files by adding the missing bits to the lower quality file. This idea could lead to a music download service where you can download a low quality preview version of a song, and if you are interested, download the missing bits to make it a high quality version."
Or, Slightly modified, You could share all your high quality oggs on a P2P network, and have your client peel it down to 'future-legal-to-share' low quality files.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Sounds more like it would be unique to OV, if they implemented it.
The point is, nobody does it now. Perhaps this is because there's really no need for it. Consider the list of "very sexy applications:"
- In a streaming situation, the server would store only one high quality stream, and dynamically peel it down to the client's bandwidth. Not useful. If you instead stored a hundred separate files, each optimized for its bitrate, with each being half the bitrate of the previous one, you'd still have a set of files less than twice the size of the largest file. Plus, you'd have no bit-peeling overhead. If you're streaming 100GB audio files, maybe there's a benefit, but if you're doing that, you can probably afford a second 100GB file for all the smaller files.
- You could store high quality Ogg Vorbis files on your PC for your Audiophile home theater setup, and peel them down to "good enough for lousy headphones on a noisy train" portable files. You can do that now, without this high-tech. Such low-quality files could be easily made from the original OV high-quality files, without much extra artifacting due to the re-encoding. And again, how low a quality are you willing to accept, if you're going this far anyway? Wouldn't you just buy a higher-cap memory card?
- Download a low quality preview version of a song, and if you are interested, download the missing bits to make it a high quality version. Another non-benefit. Suppose the full file is 10 meg, and you download a 1 meg sample. Are you really going to opt to download the 9 meg "patch" file, rather than the 10 meg complete version?
A clever idea, and it sounds cool on the outset, but it seems to me that this is a solution seeking a problem.This is exactly the killer app that Ogg needs for acceptance: a program that syncs songs to your portable player at a lower (user adjustable) bitrate. Even better: You pick out X number of songs. Each time you add a song, it re-calculates what bitrate to shave them all to, to maximize the bitrate used, thereby using all the RAM on the player but getting all your songs in.
I can't wait til this one hits.
Musi withou hig frequenc is lik wods mising leters.
-braxton
of a Slashdotter comment that twisted an old expression...
"Those who sacrafice sound quality for hard disk space deserve neither."
Cool idea to throw around though.
Why, o why must the sky fall when I've learned to fly?
One thing that hasn't been discussed here is that a lot of people feel that Vorbis is transparent at something like quality setting 4. Other people think it's transparent at quality setting 3. Others think it's great at 1. I release my stuff at 4, but bitrate peeling will let people peel those down to what sounds good to them. Maybe they want to monkey with it, and maybe they don't, but the option to do this without re-encoding is sexy.
It's not just a 'chop it down for modem folks' thing, it's also a letting people choose for themselves situation that I think is more important.
Features are cool, but features that give people options apart from 'use it or not' are even cooler.
That's it for me. Please donate to Xiph.org, and then go listen to some tunes. Enjoy!
Scalable techniques like this are very cool, but hardly novel.
MPEG-4's scalable profiles provide a similar effect (albeit in the other direction, with enhancement layers). Some of the higher end audio codecs (beyond CELP and AAC), like ER BSAC (Error Resistant Bit Sliced Arithmetic Coding) do exactly this. The idea in this case is that the server will in real-time only provide as many bits as the connection can currently provide. Very nice for wireless.
QDesign's QDX format does almost exactly what is described for Ogg, with arbitrary bitrate peeling down to the 1 Kbps level. The idea is that you could copy as much data as you want to your mobile player, and it'd dynamically thin to the data rate that would fill up your device.
And still image codecs like JPEG have used progressive modes for years, where additional data adds more detail to the image.
My video compression blog
Okay, if each one is double the one before, that means you'll have a 2^100 ratio between lowest and highest data rate. Thus, if your lowest is 1 Kbps, the highest would be... Not going to happen that way.
Also, you assume the sweet spots are 2x the one before. In fact, jumps of more like 1.25 are likely to be optimal (albeit with a lot fewer jumps!).
My video compression blog
Could it possibly be used to progressively download an Ogg file and begin listening to it before it's 100% done? For example, have the 32kbit quality at the start of the file, then next have the next 32kbit (starting at the end of the file), then the next 64kbit, etc...
Luke-Jr
There aren't ANY free lossy codecs that can do bit-peeling right now. Some non-free codecs allow you to overlay data (like progressive JPEG), which is NOT the same thing. That's just like transmitting deltas at higher compression rates, which could be done with a simple side-band for any existing method, MP3 even.
The only option is transcoding, which compounds compression errors (decode, reencode). I often wished the MPEG group would have been more intelligent in the design of their bit-allocater so that you could "thin out" the quantization of the power bands by looking at the "right parts" of the MP3 frame. Alas, this is not possible.
But the Vorbis designers have made this possible, thus making it possible to have high-quality and low-quality versions derived from the same source file without additional processing. I imagine you have certain restricted choices, due to how quantization information is bundled up/packeted. But it isn't just sexy, it would be stupid to NOT DO IT. It takes just a little forethought on how to lay out the information in a hierarchial fashion. What makes anyone think that this is any harder then decoding/reencoding. I guarantee it has a time complexity on the order of a straight copy.
Hell, formats like SHN and FLAC can do it, just substitute short codes for long codes at a certain rate; it'll add a bit of wide-band energy on decode, raising the noise floor in proportion to the space savings you gain.
So anyway, "poop on you" to all these wanna-be audiophiles/slashdot-know-it-alls who don't no a good thing when they see it.
Don't like it, keep sucking on that Layer III.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
There are a number of problems with the parent post.
1. Keeping hundreds, or even ten separate files as described, each half the size of the previous, is not plausible. I'd assume the author was a troll, but since no one else has mentioned it, perhaps the obvious fallacy with that idea is slipping past even the sharper readers. A 10MB file can be split in half at most 23 times before it is only 1 byte long, far fewer before the quality level is unacceptable. Secondly, the idea described in the article, provides for dynamic bitrates, not simply half the original bitrate. To provide even similar functionality, one would need files in ranges from 1MB to 10MB in relatively small increments, totaling well in excess the "twice the size of the largest file" as suggested. Even so, this would be deficient in that the bandwidth could not be throttled mid-stream.
2. Second, decoding and re-encoding the same file with a different bit rate will almost certainly result in poorer quality than the technique described. The safer, more straightforward solution, is to perform reduction operations on the transformed data, rather than the decompressed waveform. Otherwise, amplified artifacts from the original compression will be present in the new file.
3. Third, the strength of the poster's argument lies entirely in the choice of ratios. Downloading a 5MB file rather than a 10MB file leaves only 5MB remaining. To paraphrase, are you really going to opt to download the 10MB complete version when your software can download the remaining 5MB in half the time?
There are a number of problems which bitrate peeling address, not the least of which are 1) reduction of storage space as described previously, 2) dynamic bandwidth regulation of audio streams for streaming radio, future cellular phones, VOIP, and network appliances running on congested networks, 3) file size reduction without transcoding, 4) user-specified bandwidth on demand, 5) automatic preview generation from source without any extra administrative overhead.
I'll even add my own... the ability to download a very high quality file and start listening to it immediately at lower quality without interruption. By the time the file has played through, the download may be only 50% complete. If I decide not to continue with the download, I have wasted no more time than that necessary to listen to the file. If I want the file, I have only 50% remaining.
In some ways, this is similar to the rationale behind interleaved images, except that it is unlikely that you will need to listen to the same file repeatedly at progressively higher bitrates. Nothing prevents this of course.
-Hope
Look, it's simple.
audio enthusiasts listen to music.
audiophiles listen to equipment.
Me, I'll take the music.
That's how DTS was able to add a discrete surround channel (DTS ES) without causing problems with older receivers. Dolby can't change their header without breaking backward compatibility, which is why their extra surround channel (DD EX) is matrix encoded.
* As is generally the case, my opinions do not reflect those of my employer.
I think that the iPod does a very bad attempt at this. MP3s, encoded at 320k play back really badly on the iPod, far worse than 128/192k ones. I suspect that the iPod hardware hasn't enough horsepower - and it is discarding bits that it cannot decode fast enough. The MP3s sound fine on the pc, or decoded to wav and then played back on the iPod. But played back (as MP3) on the iPod, the result is dismal - there's a 5Hz "wobbling", rather like a steel band, and lots of distortion. (Apple won't help, but I have replicated this problem on multiple setups both Linux and OSX - it would be interesting to see if any /.ers have seen the same thing. You need a good recording of a classical CD with very large dynamic range eg Mahler 8, part II to demonstrate it - listen to the quiet bits.)
[I have some demo files, but can't link them - I'll get slashdotted off the net !]
Peel layers from a data file thin enough that no layer is independantly recognizable. Scatter the layers throughout a P2P system. Now no individual user possesses the whole file, but all users can reconstruct a working copy when they want to play it.
That Jesus Christ guy is getting some terrible lag... it took him 3 days to respawn! -NJ CoolBreeze