I was up late last night, and i had a thought on peeling that would probably provide 100% accurate peeling data to a decoder, but take a maximum of 1101 times normal time to encode (taking into account the range from q-1 to q10 ). ay you want to encode a track at q10, but you want it to be peelable. the 1101 encoder would encode from the source at every quantifiable level (since there are 2 decimal points of quality in at least oggdrop, giving 100 quantifiable levels per integer level of quality, giving 1001 from q0 to q10, and an extra 100 for q-1 to q-0.01). the 1101 encoder would then compare the resulting files (assuming that they are all from an identical source) and basically say "all those bits of data not in q9.99 to q-1 belong to q10" and keeping going through things like "all those bits of data not in q10 to q5.54 and q5.52 to q-1 belong to q5.53" all the way down to "all those bits of data not in q10 to q-0.99 belong to q-1". eventually i'm guessing you would end up with a vorbis file with all the quantifiable samples & bits of data marked for peeling, making the job theoretically much easier & muich more accurate even with peelable streaming. I didn't think it much further than that, cos i'm not a programming genius like everyone else on here, i just think a lot. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
oh yeah, and it also means that in an ogg spliter type fashion, the discarded bits of Vorbis peel (now with added vitamin C :-p ) could be saved and added back to the peeled file at a later date. this theory works for the VBR mode obviously, no idea about CBR or ABR, but there would be fewer levels of quantifiability (since theres only a maximum bitrate of 500kbps, giving 501 levels of detail, unless you count decimal places) ----- Original Message ----- From: Martin Blackwell To: vorbis@xiph.org Sent: Saturday, December 21, 2002 10:35 AM Subject: [vorbis] had a thought on peeling last night <p> I was up late last night, and i had a thought on peeling that would probably provide 100% accurate peeling data to a decoder, but take a maximum of 1101 times normal time to encode (taking into account the range from q-1 to q10 ). say you want to encode a track at q10, but you want it to be peelable. the 1101 encoder would encode from the source at every quantifiable level (since there are 2 decimal points of quality in at least oggdrop, giving 100 quantifiable levels per integer level of quality, giving 1001 from q0 to q10, and an extra 100 for q-1 to q-0.01). the 1101 encoder would then compare the resulting files (assuming that they are all from an identical source) and basically say "all those bits of data not in q9.99 to q-1 belong to q10" and keeping going through things like "all those bits of data not in q10 to q5.54 and q5.52 to q-1 belong to q5.53" all the way down to "all those bits of data not in q10 to q-0.99 belong to q-1". eventually i'm guessing you would end up with a vorbis file with all the quantifiable samples & bits of data marked for peeling, making the job theoretically much easier & muich more accurate even with peelable streaming. I didn't think it much further than that, cos i'm not a programming genius like everyone else on here, i just think a lot. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi, Well, I'm not authoritative on this subject, but from what I understand, this wouldn't work because the result of encoding a sound file is not linear. What this means is that a q10 file is not just a q9 file with some extra data. Or to explain it a different way, a q9 file is not a subset of a q10 file. I thought of something similar a while back (check the June 2001 archives). My idea was that you could stream, for example, a q1 file and in a different stream all the peeled-off information that would turn the q1 stream into a q2 stream. I was told this was not possible because a q2 file is not just a q1 file with extra bits. Alex On Sat, 2002-12-21 at 10:35, Martin Blackwell wrote:> I was up late last night, and i had a thought on peeling that would probably provide 100% accurate peeling data to a decoder, but take a maximum of 1101 times normal time to encode (taking into account the range from q-1 to q10 ). > > say you want to encode a track at q10, but you want it to be peelable. > the 1101 encoder would encode from the source at every quantifiable level (since there are 2 decimal points of quality in at least oggdrop, giving 100 quantifiable levels per integer level of quality, giving 1001 from q0 to q10, and an extra 100 for q-1 to q-0.01). > the 1101 encoder would then compare the resulting files (assuming that they are all from an identical source) and basically say "all those bits of data not in q9.99 to q-1 belong to q10" and keeping going through things like "all those bits of data not in q10 to q5.54 and q5.52 to q-1 belong to q5.53" all the way down to "all those bits of data not in q10 to q-0.99 belong to q-1". > eventually i'm guessing you would end up with a vorbis file with all the quantifiable samples & bits of data marked for peeling, making the job theoretically much easier & muich more accurate even with peelable streaming. > > I didn't think it much further than that, cos i'm not a programming genius like everyone else on here, i just think a lot.<p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
('binary' encoding is not supported, stored as-is)
Shawn Riley wrote:
> Could that be continued to levels q0 & q-1 to produce a total of 4
streams?
> Is such a level of "granularity" considered acceptable? I thought
the
intention> was to be able to peel the streams to /any/ given q-level, not just
specific
> levels. I wonder then, could it start pulling a few bits off the high
frequency> range, then gradually lower this "cutoff" frequency (one stream
at a time)
> while the simulated q-level drops?
Well I also think peeling is supposed to "convert" any quality-level
into any
level below that.
The problem here is: we want to stream some music (maybe a radiostation or
something) and we'd like to use as low bandwidth as possible. Now instead of
having two complete streams, one in q1 and one in q2 (where the q1-one may be
peeled from the q2-one), we may reduce the bandwidth by sending a q1 and the
additional data which makes it q2. So people are free to chose which quality
they want and we're not "wasting" our bandwidth.
I dont know how efficient it would be to provide even more streams. But basicly
this should work by taking a q2, peeling it down to a q1, peeling this down to
a q0 and peeling this down to a q-1. We then have a q-1 and the difference from
each level to the next. Listening to the q2 would require to use *all 4*
streams.
This will surely lead to some other problems and it'd maybe be easier to
just
use the simple method twice.
-- Daniel
<p>> Daniel wrote-> > stream a q2 peeled down to q1 and in a second stream all the data the
peeler> > threw away.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
('binary' encoding is not supported, stored
as-is)> Daniel wrote-
> >Did you mean to take like the first half of the packet (with wathever
> >frequencies in there)? If yes, that's probably how peeling works.
>
> That's precisely what I was saying. But for the next part of your
reply, what
> I meant was for the server to do the peeling instead - pass the
"base"
streams> through, then cause the peeler on the server to break bits off one of the
end
> of the "reconstitution" streams to adjust for the bandwidth.
Ah, I think I got your idea: the server provides every listener a stream, with
individually adjusted bandwith. And your method is a speed improvement over
peeling for everybody in a seperate task. This would probably be a nice idea.
Since the parts that are individual can be very small with the server sending a
base stream and individual additions.
Don't know if it actually could work...depends on the internal format of
Vorbis
and the "peel-addons".
> I wrote-
> >> Is it possible to convert an existing vorbis stream into a
peelable stream
> >> just by reorganising the bits?
> >
> Daniel responded with-
> >Hmmm...as far as I got it: the streams (files) Vorbis 1.0 produces are
> >already
> >peelable. (There exist a few *inoffical* tools to do it; search the
archives
> >for links.) It's just that the result isn't that good. With a
little work on
> >it, the quality could be (much?) better for peeled streams/files.
>
> Sure, if we encode 10 CDs' worth of audio to Vorbis 1.0, then wish to
peel it
> to a lower bitrate, then it could be done right now, but for what I
> understand, a q6 stream peeled to the same bitrate as a q1 stream, will
> probably sound worse than a q1.
That's correct.
> So what I wanted to know was, is it possible to take a current
> stream & reorganise the bits to give a current peeler the best possible
> output?
> This would be useful for batch processing, in a radio station or by a DJ
that
> has a 100-CD collection of Vorbis files encoded with ver1.0. They won't
want
> to re-rip/re-encode/re-tag, & will want to use a simple peel function
to make
> it easier on the server.
Hmmm...this an important question (I also don't want to reencode all my
stuff
:)
It also depends on the internal Vorbis format...although I think it should be
possible...I can't imagine xiph wants to change half of the vorbis format to
improve peeling. I suppose they'll think of a better way to organize the
bits
and this should basicaly allow to apply it to already existing files.
But this question can't be answered right now...it heavily depends on how
the
encoders change the output-style to improve peeling support, and this feature
is still to be implemented.
-- Daniel
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.