Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: .Ogg Vorbis aotuv (Read 496400 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

.Ogg Vorbis aotuv

Reply #325 –
Quote from: PatchWorKs on
Technical question: could LAME bs code be used into "Greebo" ?

It is impossible unless somebody remodels the cord. And the somebody tunes it up and must test it.

Quote
Another idea: is it possible to separate the bs algorithm from the encoder ?
If so, it could be en external library that may be exchangable between various codec's encoder engines...

That there is the person who is going to carry it out is a problem.
If I think, probably it does not balance with labor.

.Ogg Vorbis aotuv

Reply #326 –
Dear Aoyumi, could you please say some words about future integration aotuv into libvorbis 1.3.0.
What will be the base? Will be it beta 5.7 code or anything else?

.Ogg Vorbis aotuv

Reply #327 –
Quote from: alter4 on
Dear Aoyumi, could you please say some words about future integration aotuv into libvorbis 1.3.0.
What will be the base? Will be it beta 5.7 code or anything else?

There is not the matter that I can say about libvorbis 1.3.0 for the moment, sorry.

.Ogg Vorbis aotuv

Reply #328 –
Hi Aoyumi,

If there is no problem with BS1, plz do a small stable (Edit: well I mean Beta) release before Monty swallows your code.

I don't use Vorbis for music actually but I still care for it if sites like wikipedia use xiph's codecs.

In all honesty I didn't test BS1 heavyly outside my listening test, but I recall it fixed a nasty bug without any noticeable regression. Even very small & specific the improvement on this particular bug was real.

It happens so rarely that Monty swallows aotuv that I don't want to wait 2 years for BS1 improvement to be merged

.Ogg Vorbis aotuv

Reply #329 –
+1

.Ogg Vorbis aotuv

Reply #330 –
Although BS1 did fix a major bug. The bitrate has increased a fair amount. Most things end up about 10-20kb higher than the target bitrate.

So I am not sure if it would be good to merge BS1 into libvorbis in its current state.

.Ogg Vorbis aotuv

Reply #331 –
Bitrate is an issue indeed but I'd rather waste some space & make a step toward transparency than leaving bugs unfixed ... the problem is that if you target transparency & use ... say - q6 or above, then BS1 is a better choice than aotuv 5.7 ... if you don't care for transparency & use something below - q5 then the BS1 fixe doesn't matter because at mid-low bitrates vorbis has other problems that prevent it from being transparent anyway. It's a matter of choice, do you want real transparency or cheap overall efficiency with bugs. In other words BS1 is not really great for streaming, but if you're an audiophile making CD backup then it is necessary to fix as much bugs as possible IMHO. It must be the reason why I don't really use Vorbis anymore ...

.Ogg Vorbis aotuv

Reply #332 –
Quote from: sauvage78 on
If there is no problem with BS1, plz do a small stable (Edit: well I mean Beta) release before Monty swallows your code.

I don't use Vorbis for music actually but I still care for it if sites like wikipedia use xiph's codecs.

In all honesty I didn't test BS1 heavyly outside my listening test, but I recall it fixed a nasty bug without any noticeable regression. Even very small & specific the improvement on this particular bug was real.

It happens so rarely that Monty swallows aotuv that I don't want to wait 2 years for BS1 improvement to be merged

I can't yet include bs1 in beta release for test lack.
However, I will open the source code immediately if somebody needs it. 

Quote from: Xanikseo on
Although BS1 did fix a major bug. The bitrate has increased a fair amount. Most things end up about 10-20kb higher than the target bitrate.

So I am not sure if it would be good to merge BS1 into libvorbis in its current state.

It is not a bug. The bit rates increase if necessary. And the quantity depends on sources really.

.Ogg Vorbis aotuv

Reply #333 –
Ah!. I can help you with joy, but my ears are not too for music)
I am not an authority as Guruboolez, though my asus xonar and koss portaPro are good for something)

.Ogg Vorbis aotuv

Reply #334 –
I decided to ABX test five tracks at q4 encoded with beta5.7 and BS1 encoder. Are any recommendations for samples?

.Ogg Vorbis aotuv

Reply #335 –
BS1 is a fix for the Rush sample from this ABX test ... I doubt you can ABX any difference (positive or negative) on any other problem sample. Good luck anyway.

.Ogg Vorbis aotuv

Reply #336 –
I just have One request, Could somebody compile both BS1 and 5.7 in 64bit for some basic testing?

No special optimizations needed just whatever the compiler has built in, Lame saw a 25% perf boost just from being compiled in x64, I would like to see if there would be any perf boost for vorbis from 64bit 

Oh and Aoyumi, Thank you very much for your hard work, I am a long time vorbis supporter and my last 2 portable players have been bought spicificly for their vorbis support, Your work on Vorbis has kept it at the top of my short list for lossy codecs(along with musepack).

I would just really like to at least beable to do some testing on x64 native code(dont worry, im an old skool beta tester, so bugs wont upset me at all)

Thanks again.

P.S. I have 5 other people lined up willing/excited to test an x64 compile of oggenc

.Ogg Vorbis aotuv

Reply #337 –
Thank you for responses.

What is careful for the beta release exhibition that I incorporated BS1 in is because a other problem may spread by the change.

Then I showed the BS1 patch some time ago.
Anyone can use it with a under license same as the aoTuV.

.Ogg Vorbis aotuv

Reply #338 –
[semi-OT]: does anyone heard about this project ?

Quote
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.

Primary goals
  • Improve sandboxing of memory allocation.
  • Improve performance on low-end (embedded/portable) platforms.
  • Use only fixed-point operations, with no perceptible cost to quality.
  • Be more maintainable than libvorbis, being written in a more modern, C++ style.
  • Be as fast as existing implementations both on desktop and portables.


Future goals
  • Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
  • Play around with alternative encoder algorithms.


Also in this project
  • A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.


...we can ask him to implement a different BS algorithm, don't you ?

.Ogg Vorbis aotuv

Reply #339 –
[semi-OT] Does anyone heard about this "alternative Vorbis" implementation ? (that seems active)

Quote
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.

Primary goals
  • Improve sandboxing of memory allocation.
  • Improve performance on low-end (embedded/portable) platforms.
  • Use only fixed-point operations, with no perceptible cost to quality.
  • Be more maintainable than libvorbis, being written in a more modern, C++ style.
  • Be as fast as existing implementations both on desktop and portables.

Future goals
  • Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
  • Play around with alternative encoder algorithms.

Also in this project
  • A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.


...just mailed him.

.Ogg Vorbis aotuv

Reply #340 –
Quote from: PatchWorKs on
[semi-OT] Does anyone heard about this "alternative Vorbis" implementation ? (that seems active)

Quote
Om is a from-scratch implementation of the Vorbis I audio compression specification. It does not use any code from the existing xiph.org libvorbis or libtremor implementation.

Primary goals
  • Improve sandboxing of memory allocation.
  • Improve performance on low-end (embedded/portable) platforms.
  • Use only fixed-point operations, with no perceptible cost to quality.
  • Be more maintainable than libvorbis, being written in a more modern, C++ style.
  • Be as fast as existing implementations both on desktop and portables.

Future goals
  • Fixed-point encoder, suitable for real-time usage on embedded/mobile platforms.
  • Play around with alternative encoder algorithms.

Also in this project
  • A from-scratch implementation of the FLAC lossless audio compression specification. This has a placeholder name "specflac", and implements only the decoder, for now.


...just mailed him.

.Ogg Vorbis aotuv

Reply #341 –
Hi Guys
I was wondering if is the time for us to know more about future integration aotuv into libvorbis 1.3.0.
and if has anybody compile both BS1 and 5.7 in 64bit for some basic testing as AshenTech requested it? (just curious about the results)

Are there any plans about a new release of AoTuv's codec?
presenting new features or bug fixes?

.Ogg Vorbis aotuv

Reply #343 –
Cool...  I just wonder what was the change (specific)...    where it is at currently so far suits me... but if it improves... why not...    I know I won't regret such a cool codec... 
The other project from the "alternate vorbis" implementation, looks pretty interesting. 
Besides  (q-2) 32kbps sounds decent on generally the "rap" genre...  "Example of music that isn't very complex..." 
 

.Ogg Vorbis aotuv

Reply #345 –
I would very much like to know what this "important change of plan" is! 

It's great to see Vorbis still being worked on, particularly aoTuV!

.Ogg Vorbis aotuv

Reply #347 –
Does it say something bad about my ears that I can encode with this down to q-1.0 and still have it be transparent?

.Ogg Vorbis aotuv

Reply #348 –
Indeed your lucky. I find it too noisy below Q3-4.

.Ogg Vorbis aotuv

Reply #349 –
Ah, you're right. It is pretty noisy on very busy tracks, but for ~80% of the samples I've tested it on it ends up completely transparent. Note that I haven't trained myself to hear such things as pre-echo artifacts, but if they exist they certainly aren't obvious enough for an untrained ear to pick up.