Hi All,
Ours is an embedded software solutions company that focuses on developing embedded software solutions specific to the DSP market. Today we have released free trial version of the VINJEY ogg vorbis decoder available for download.
http://www.vinjey.com/ogg_downloads.html (http://www.vinjey.com/ogg_downloads.html)
On the downloads section we have provided experimental version of the bitrate peeler. This bitrate peeler reduces the bitrate by cutting the packets based on the factor input provided by the user. Source code of this experimental bitrate peeler comes along with our free trial version of the decoder.
Regards,
Vinoth
I've tried, and it's amazingly fast!! Wow
But quality is, hmmm, unusable.
I've peeled a q6 encoding at various level [original size : 6 571 kb / 172 kbps]
• 0.9 : 6 571 -> 5 909 KB (154 kbps): some ringing problems, but limited impact.
• 0.8 : 6 571 -> 5 257 KB (137 kbps) : ringing starts to be annoying, sometimes *really*annoying.
• 0.7 : 6 571 -> 4 601 KB (120 kbps) : poor quality, with terrible artifacts. Quality is lower than 64 kbps original encoding.
• 0.6 : 6 571 -> 3 949 KB (103 kbps) : now, it starts to be horrible, even on my laptop poor -telephone quality- speekers. Could be compared to 48...64 kbps WMA quality.
• 0.5 : 6 571 -> 3 288 KB (82 kbps)
• 0.4 : 6 571 -> 2 629 KB (69 kbps) : positive point: it keeps a lot of high frequencies. But artifacts are too obvious, even for untrained people.
• 0.3 : 6 571 -> 1 974 KB (52 kbps) : unlistenable.
Question: could quality be improved?
I kept the same track, start to encode it at q10 (500 kbps/423 kbps for true), before peeling. Reducing the size from 66% (bpeel 0.33) in order to obtain a portable friendly bitrate (140 kbps): quality is terrible, despite of 'high' bitrate !? WMA@64 kbps are not as bad.
'Shrinked' at 50%, quality starts to be acceptable. There are artifacts (unacceptable for the bitrate, mainly warbling), but overall quality is correct. Bitrate is 212 kbps (corresponding to an original q7 encoding).
At 60% of original size (254 kbps), quality becomes really decent (few artifacts, but some warbling problems are still there).
These warbling issues are still easily audible at 80% (339 kbps), and could also be noticed at 90% (381 kbps).
Guruboolez did you try to compare to transcoded files? I mean, having that 172kbps OggVorbis file as the source, which one sounds better - the same file peeled to 82kbps, or the same file transcoded to 82kbps? AFAIK peeling is supposed to give better quality than transcoding within the same format...
Anyway, it's good to have the very first bitrate peeler (correct me if I'm wrong). Keep improving it vinjey
Anyway, it's good to have the very first bitrate peeler (correct me if I'm wrong). Keep improving it vinjey
[a href="index.php?act=findpost&pid=299355"][{POST_SNAPBACK}][/a]
You are wrong
There was another peeler before, but it had also bad quality (and iirc, some bugs as well).
well, the bad quality is no surprise. Just chopping away data from the end of the packets won't ensure the "more important" data is preserved. This is not the peeler's but the encoder's fault as it doesn't sort data inside the packet according to their impact on quality AFAIK.
AFAIK peeling is supposed to give better quality than transcoding within the same format...
[a href="index.php?act=findpost&pid=299355"][{POST_SNAPBACK}][/a]
If you re-encode the file, psymodel is applied.
AFAIK, when you peel, it isn't.
That's why peeling is not a useful option, anyway…
If you re-encode the file, psymodel is applied.
AFAIK, when you peel, it isn't.
That's why peeling is not a useful option, anyway…
[a href="index.php?act=findpost&pid=299723"][{POST_SNAPBACK}][/a]
Can't a peeler use the same psymodel as the encoder, to somehow peel the bits with the least impact? (I'm a n00b)
Can't a peeler use the same psymodel as the encoder, to somehow peel the bits with the least impact? (I'm a n00b)
[a href="index.php?act=findpost&pid=299749"][{POST_SNAPBACK}][/a]
This complexity could be avoided if the encoder just arranged data within the packets in such a way that the most important information was at the beginning of each one. Then the peeler could trust the original encoder's psymodel evaluation and truncate the packets, leaving optimal quality at the desired bitrate, with no extra complexity. Measure once, cut twice, one might say?
This complexity could be avoided if the encoder just arranged data within the packets in such a way that the most important information was at the beginning of each one. Then the peeler could trust the original encoder's psymodel evaluation and truncate the packets, leaving optimal quality at the desired bitrate, with no extra complexity. Measure once, cut twice, one might say?
[a href="index.php?act=findpost&pid=299751"][{POST_SNAPBACK}][/a]
A really good idea, and I take it that oggenc doesn't arrange the data in this way yet...
And now for the million dollar Question: Why doesn't the encoder do this?
Is this so hard to do, or is it a chicken and egg problem, noone bothering because there weren't any peelers?
Or was it Vorbis' design philosophy that the peeler itself would have to be intelligent and apply proper selection on what to throw away and what to keep?
I wish i had answers..
Nope, not yet. I've never really looked at the code, so I dunno how hard it'd be to modify the current encoders to arrange the data in such a way. I do know that there was discussion (long past) about writing a utility that would losslessly rearrange the data in existing sub-optimal streams to increase their quality when peeled. Unfortunately, I don't think any actual utility was ever released, since nobody with the required coding ability and internal understanding took up the "bounty" on peeling.
And now for the million dollar Question: Why doesn't the encoder do this?
Is this so hard to do, or is it a chicken and egg problem, noone bothering because there weren't any peelers?
Or was it Vorbis' design philosophy that the peeler itself would have to be intelligent and apply proper selection on what to throw away and what to keep?
I wish i had answers..
[a href="index.php?act=findpost&pid=299753"][{POST_SNAPBACK}][/a]
I would think that it would be impressively difficult for the encoder to determine exactly which bits to consider above the rest, as it would require something like a feedback loop in the psymodel.
It seems that the encoder would have to know what it would choose to encode at q4.0, then what it would choose at q3.0, then at q2.0, and place the difference, in decreasing order, at the end of the packets.
Details would be arranged in such a fashion: [q-1][q0][q1][q2][q3][q4]
This may be easily possible, I have no idea how the psymodel works currently. The simplest, but most computationally intensive method, would just be to calculate certain "key" quality values from the desired original value downward, and do the aforementioned detail-sorting... but that's far from optimal complexity efficiency, I would think. If only there were "bit-wavelets."
Hi All,
Thanks for the testing and inputs provided so far.
We have implemented this bitrate peeler primarily to test the new decoder developed by us. To put it in other words, bpeel is one of the 14 tools we developed and tested the decoder. So we didn't have really much of chance to check the bpeel as a tool and hence bpeel was released without much or no internal testing.
Now with inputs from different people on mailing lists, forums and emails we have found how much importance people give for a bitrate peeler without any noise ;-). This has kindled interest among our engineers to start working on bitrate peeler. Once we have some updates on our work on bitrate peeler we will post back the results.
Regards,
Vinoth
Now with inputs from different people on mailing lists, forums and emails we have found how much importance people give for a bitrate peeler without any noise ;-). This has kindled interest among our engineers to start working on bitrate peeler. Once we have some updates on our work on bitrate peeler we will post back the results.
Regards,
Vinoth
[a href="index.php?act=findpost&pid=300258"][{POST_SNAPBACK}][/a]
Great! Thank you very much and go on! Every trip begins from the first step. And it's done. It would be very good to have a good peeler.
Anyway, it's good to have the very first bitrate peeler (correct me if I'm wrong). Keep improving it vinjey
[a href="index.php?act=findpost&pid=299355"][{POST_SNAPBACK}][/a]
You are wrong
There was another peeler before, but it had also bad quality (and iirc, some bugs as well).
[a href="index.php?act=findpost&pid=299356"][{POST_SNAPBACK}][/a]
Minor correction: There were three peelers prior to this. The first two were by segher. One was called Rhubarber, but I cannot remember the name of the other one, except that it sounded vaguely Nordic.
The third contestant seems to be something called specbis, which primarily aims to be an independant Vorbis implementation, but has peeling capabilities as well.
Minor correction: There were three peelers prior to this. The first two were by segher. One was called Rhubarber, but I cannot remember the name of the other one, except that it sounded vaguely Nordic.
[a href="index.php?act=findpost&pid=300865"][{POST_SNAPBACK}][/a]
Aardappelschilmesje
It's Dutch.
Heh. Thanks. So.. aard means ground (like in aardvark), appel means apple, aardappel means potato, and aardappelschilmesje means potato peeler?
Exactly.
aardappelschilmesje means potato peeler?
Exactly. It's simple. The dutch kinda speak german
aard appel schil mesje == erd apfel schäl messer = Kartoffelschälmesser.
lol does that mean "ground apple" ?
lol does that mean "ground apple" ?
[a href="index.php?act=findpost&pid=337188"][{POST_SNAPBACK}][/a]
Yep, the French use the same phrase - "pomme de terre" = apple of the earth = potato.
I wouldn't translate 'aarde' to 'ground', 'soil' or 'mould' are better translations.