.Ogg Vorbis aotuv, Question for Aoyumi Options

[alter4]

Venc doesn't support adding vorbis tags!
I want exactly what I want.

[saratoga]

Aoyumi:

I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions. Is there some way to predict how much memory various aoTuV encodes will use? Or at least someway for a user to know that a given file won't require an excessive amount of memory for a portable device?

I realize the vorbis spec does not put a limit on how much memory a file can use, but many MP3 players have only so much RAM on the device.

[Lear]

I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions.

That's odd... The only Vorbis files I've seen that Rockbox failed to decode and weren't using floor0, failed due to really large comments packets (i.e., big album art). I haven't used any low memory target though, if that makes any difference.

[Aoyumi]

Aoyumi:

I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions. Is there some way to predict how much memory various aoTuV encodes will use? Or at least someway for a user to know that a given file won't require an excessive amount of memory for a portable device?

I realize the vorbis spec does not put a limit on how much memory a file can use, but many MP3 players have only so much RAM on the device.

The memory consumption of "aoTuV" cannot have a wide margin than "Xiph.Org's libvorbis".
I never did the change that influenced memory consumption greatly.
Generally quantity to use depends on setup header size.

I've noticed various Vorbis files that failed to decode in rockbox over the years due to lack of memory, and aside from a few very old files using floor0, nearly all were encoded with various aoTuV versions.

That's odd... The only Vorbis files I've seen that Rockbox failed to decode and weren't using floor0, failed due to really large comments packets (i.e., big album art). I haven't used any low memory target though, if that makes any difference.

The size of ogg page and/or comment header seems to surely become the problem.
At first decoder should scan header part.

[saratoga]

The memory consumption of "aoTuV" cannot have a wide margin than "Xiph.Org's libvorbis".
I never did the change that influenced memory consumption greatly.
Generally quantity to use depends on setup header size.

Edit: Yeah, looks like this one had a huge album art image in the header I missed. Still i'm surprised this allocates memory in rockbox. I gutted a lot of the metadata code in tremor a while ago, didn't realize album art was still being parsed.

This post has been edited by saratoga: May 3 2011, 04:32

[Lear]

Edit: Yeah, looks like this one had a huge album art image in the header I missed. Still i'm surprised this allocates memory in rockbox. I gutted a lot of the metadata code in tremor a while ago, didn't realize album art was still being parsed.

It isn't parsed, but the packet is still buffered by the Ogg layer.

[Nicos]

I need your help guys
I usually download the generic compile from john33 i unrar the file, i open dbpoweramp locate the oggenc2.exe and convert in .ogg with dbpoweramp converter, I did the same with the new version and i got the error: "error writing audio data to StdIn pipe"
Does anyone can help me with this?

[Nezmer]

Hi,

I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.

Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?

This post has been edited by Nezmer: May 6 2011, 21:16

[alter4]

I am not sure 100% but suppose at q7 new values of impulse_noisetune impulse_trigger_profile are applied. As result - bit rate bloat.

[Skarecrow]

Hi,

I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.

Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?

I've seen something that happen between 3.9 and 4.0 where the noise shaping crossover is (actually, the reverse. 3.9 is slightly more bitrate intensive than 4.0). I didn't see it at 5.9 to 6.0 though, where the joint stereo crossover (well, the vorbis equivalent) is. not sure what may be going on between 6.9 and 7.0. Maybe the aggressive quality tuning gives out past the q6 range?

[alter4]

Nezmer.
Hum... I suppose you specified q as -q6,99999 but not -q6.99999
because 6.999999 = 6 for encoder

P.S. Anyway if do it right the difference in bitrate is 15kbps in my case

This post has been edited by alter4: May 6 2011, 21:50

[Nezmer]

Nezmer.
Hum... I suppose you specified q as -q6,99999 but not -q6.99999
because 6.999999 = 6 for encoder

P.S. Anyway if do it right the difference in bitrate is 15kbps in my case

6.9999 as -aq (ffmpeg) and -q(oggenc).

15kbps is about right with (average) files.

It goes from 245.3 to 272.6 with El Carretero(track 8 from Buena Vista Social Club). A bitrate-hungry track, It seems.

[alter4]

CODE

C:\1>oggenc2.exe -q6.9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
         "699.ogg"
at quality 6,00
        [ 99,9%] [ 0m00s remaining] \

Done encoding file "699.ogg"

        File length:  1m 25,0s
        Elapsed time: 0m 03,0s
        Rate:         28,5863
        Average bitrate: 181,8 kb/s


C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...

New logical stream (#1, serial: 00001215): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100

Nominal bitrate: 192,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
        Total data length: 1949210 bytes
        Playback length: 1m:25.758s
        Average bitrate: 181,831599 kb/s
Logical stream 1 ended

C:\1>oggenc2.exe -q6,9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
         "699.ogg"
at quality 7,00
        [ 99,6%] [ 0m00s remaining] |

Done encoding file "699.ogg"

        File length:  1m 25,0s
        Elapsed time: 0m 02,0s
        Rate:         42,8795
        Average bitrate: 221,5 kb/s


C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...

New logical stream (#1, serial: 000003ed): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100

Nominal bitrate: 224,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
        Total data length: 2374406 bytes
        Playback length: 1m:25.758s
        Average bitrate: 221,495908 kb/s
Logical stream 1 ended

C:\1>

Do you see?

[Nezmer]

CODE

C:\1>oggenc2.exe -q6.9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
         "699.ogg"
at quality 6,00
        [ 99,9%] [ 0m00s remaining] \

Done encoding file "699.ogg"

        File length:  1m 25,0s
        Elapsed time: 0m 03,0s
        Rate:         28,5863
        Average bitrate: 181,8 kb/s


C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...

New logical stream (#1, serial: 00001215): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100

Nominal bitrate: 192,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
        Total data length: 1949210 bytes
        Playback length: 1m:25.758s
        Average bitrate: 181,831599 kb/s
Logical stream 1 ended

C:\1>oggenc2.exe -q6,9999999 Alouette.wav -o 699.ogg
Opening with wav module: WAV file reader
Encoding "Alouette.wav" to
         "699.ogg"
at quality 7,00
        [ 99,6%] [ 0m00s remaining] |

Done encoding file "699.ogg"

        File length:  1m 25,0s
        Elapsed time: 0m 02,0s
        Rate:         42,8795
        Average bitrate: 221,5 kb/s


C:\1>ogginfo.exe -v 699.ogg
Processing file "699.ogg"...

New logical stream (#1, serial: 000003ed): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100

Nominal bitrate: 224,000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
        Total data length: 2374406 bytes
        Playback length: 1m:25.758s
        Average bitrate: 221,495908 kb/s
Logical stream 1 ended

C:\1>

Do you see?

Never used oggenc2.
Float values are accepted in the tools I use (As far as I know).
ffmpeg rounds to 7 with 6.9999999. oggenc with 6.999999.

[alter4]

Ok
The purpose is to show 6.999999 = 6 for oggenc encoder
The difference in 15 kbps I got with q value 6,999 for oggenc

[LordWarlock]

The separator depends on the system locale, so for some languages 6.999 is correct and for other languages you have to use 6,999.

[Aoyumi]

Hi,

I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.

Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?

Some parameters are not interpolated in libvorbis. And they increase than libvorbis 1.3.2 in "aoTuV beta6.03".
It is a cause of a big difference of bitrate.

These are not bugs.

[Nezmer]

Hi,

I see a big difference in average bitrate going from quality 6.9999 to 7. That does not happen with Xiph's libvorbis.

Is this happening because a certain filter/setting changes by default at quality 7? Or is it a bug somewhere?

Some parameters are not interpolated in libvorbis. And they increase than libvorbis 1.3.2 in "aoTuV beta6.03".
It is a cause of a big difference of bitrate.

These are not bugs.

Thank you for your answer.

[alter4]

The separator depends on the system locale, so for some languages 6.999 is correct and for other languages you have to use 6,999.

Oh! Shame on me! It is quite obvious.

[Nicos]

I need your help guys
I usually download the generic compile from john33 i unrar the file, i open dbpoweramp locate the oggenc2.exe and convert in .ogg with dbpoweramp converter, I did the same with the new version and i got the error: "error writing audio data to StdIn pipe"
Does anyone can help me with this?

anyone who understands to help me?

[lvqcl]

Open command prompt window and try to encode .wav file using oggenc2 directly.

[alter4]

There is a hard sample for beta 6
link

[sergiomc]

Hi everyone, one question. I'm encoding with the new version of Aotuve and the previous version, at setting -q4.
With the new version the size from a ripped CD is from 5 to 10 mb greater.
Why is that ?? It means the new aoutuve is better or maybe, the new q4 is now q3 ??


Greetings from Peru

SergioMC

[moozooh]

It means the new version decides to allocate more bits to preserve a certain level of quality. Theoretically this level of quality should be somewhat higher than what the previous version output at -q4, and probably higher than what the previous version output at the same bitrate values.

How many hours of audio material have you tested so far? 2-3 in the same style, or 20-30 in different styles? You need as much data as possible for representative statistics.

[krafty]

I have a question: Will aoTuV ever hit "Release 2" status?