vorbis-tools 1.4.0, libvorbis 1.3.1, and libao 1.0.0 coordinated relea, March 26, 2010 Xiph's news Options

[forart.eu]

libao 1.0.0 released
libVorbis 1.3.1 released
vorbis-tools 1.4.0 released

Xiph.Org announces the release of libao-1.0.0, libvorbis-1.3.1 and vorbis-tools-1.4.0. This is a coordinated update of the audio libraries and tools to deploy improved surround-sound support across the libraries and toolchain.

libao improvements

• AO returned to active development
• Added surround channel mapping API and capability
• Updated all drivers on modern installs
• New config file options
• Driver options may be specified in config file
• Support for MacOSX updated to 10.5 and later
• Build in WMM driver rather than using dlopen()
• Added Roar Audio driver
• Added OpenBSD SNDIO driver
• Workaround for ESD non-4096 byte write bug
• Workaround aRts server crash bug
• Workaround for VIA82xx click/crackle bugs under ALSA
• Remove dead/unused drivers (solaris, alasa05, mmsound)
• Numerous patches from multiple downstreams

libvorbis improvements
libVorbis 1.3.0 was briefly available as an unreleased staging snapshot. This official release bumps the version number to 1.3.1 to avoid any possible confusion.

• Optimized/coupled surround support for 5.1 encoding at 44.1/48kHz
• Added encoder control call to disable channel coupling
• Corrected an overflow bug in very low-bitrate encoding on 32 bit machines that caused inflated bitrates
• Numerous API hardening, leak and build fixes
• Correct bug in 22kHz compand setup that could cause a crash
• Correct bug in 16kHz codebooks that could cause unstable pure tones at high bitrates

vorbis-tools improvements
vorbis-tools 1.4.0 is the first official release of vorbis-tools since 1.2.x. 1.3.x was never offered as an official snapshot, though various versions were widely deployed as patch-sets by distributions.

• Implement corrected channel mappings for all input and playback file types
• Correct an possible infinite loop in WAV input reading code when header is corrupt
• Implement "disable_coupling" option for oggenc
• Fix Ctrl-C lockup bug in ogg123
• ogg123 directory playback in sorted order
• Add WAVEFORMATEXTENSIBLE support
• More translations
• Add '-' as stdin/out filename in vcut
• Add -lnetwork check for socket in configure
• Remove 'extra' F parameter from ogg123 remote output
• Numerous code and build fixes

Downloads

The libao 1.0.0 release is available from http://downloads.xiph.org/releases/ao/

The libvorbis 1.3.1 and vorbis-tools 1.4.0 releases are available from http://downloads.xiph.org/releases/vorbis/

Happy hacking!

Monty
Xiph.Org

This post has been edited by greynol: Mar 26 2010, 23:06

Reason for edit: Removed post icon.

[john33]

libogg 1.2.0 is also part of this release.

I'll produce a set of new compiles through the day and post back here when they're available.

[forart.eu]

Yep, was a yesterday release...

john33, time for x64 builds too ?

[john33]

Yep, was a yesterday release...

john33, time for x64 builds too ?

Very probably!

[HotshotGG]

Sweet I wonder if the Ubuntu team has made a x86_64 debian compile for Linux yet! I will update my dependencies.

[john33]

I'll produce a set of new compiles through the day and post back here when they're available.

I am progressing through these, there are just a few more code changes than expected.

For the main builds, I am proposing providing win32 Generic, win32 P4 and win64 builds. From initial testing, the win64 builds look a fair bit quicker, but I've not done any exhaustive testing. Just for the record, I am building and testing on a q6600 @ 3.2GHz, 8GB RAM running Windows 7 64 bit Ultimate (fully up-to-date) and using ICL 11.1.054.

I should have all the builds ready later this evening, but I'll post back here.

[john33]

I'm afraid these may not be completed until tomorrow now as the changes are not going quite as easily as was hoped. Sorry about this, but I'd rather try to get this right than rush them out and get it wrong.

[viktor]

what changes are you making? will you try to get the fixes go upstream?

[nycjv321]

does this version of libvorbis incorporate the latest aotuv build? or a better question which would be understood to give better quality?

This post has been edited by nycjv321: Mar 26 2010, 23:10

[HotshotGG]

does this version of libvorbis incorporate the latest aotuv build? or a better question which would be understood to give better quality?

No it does not. Monty said he was concerned about any sort of regressions if I understand the release notes above. I am sure they will be incorporated eventually!, but he also might want to double check the source. It happens. The problem with continuously tuning the encoder is just that in some cases there are regressions.

This post has been edited by HotshotGG: Mar 26 2010, 23:37

[john33]

OK, there is a full set of compiles now on Rarewares, but no 64 bit builds at present. The reason for the delay in putting these up was that I was trying to resolve some issues with 64 bit builds but they are still outstanding, at the moment. I will continue to work on these, but I didn't want to delay the availability of the standard compiles any longer.

[viktor]

OK, there is a full set of compiles now on Rarewares, but no 64 bit builds at present. The reason for the delay in putting these up was that I was trying to resolve some issues with 64 bit builds but they are still outstanding, at the moment. I will continue to work on these, but I didn't want to delay the availability of the standard compiles any longer.

what problems do you face? i'm also maintaining a few builds, so i may already have faced similar problems.

[Dukers]

Good to see Xiph projects alive again. I'm looking forward to seeing aotuv improvements incorporated in official libvorbis.

[forart.eu]

OK, there is a full set of compiles now on Rarewares, but no 64 bit builds at present.

[callmeace]

Thanks for the windows builds

Is there going to be a Vorbis Tools package built for Windows also?
I tried to download what I thought would be the binary from:
http://downloads.xiph.org/releases/vorbis/...tools-1.4.0.zip

..but it contains source files!

Thankyou again

[tebasuna51]

The windows binaries from Rarewares have many problems with channel mapping.
The sources don't coincide with vorbis-tools 1.4.0, at least with the necesary remap of multichannel wav input.

in audio.c vorbis-tools 1.4.0 there are:

CODE

static int wav_permute_matrix[8][8] =
{
  {0},              /* 1.0 mono   */
  {0,1},            /* 2.0 stereo */
  {0,2,1},          /* 3.0 channel ('wide') stereo */
  {0,1,2,3},        /* 4.0 discrete quadraphonic */
  {0,2,1,3,4},      /* 5.0 surround */
  {0,2,1,4,5,3},    /* 5.1 surround */
  {0,2,1,4,5,6,3},  /* 6.1 surround */
  {0,2,1,6,7,4,5,3} /* 7.1 surround (classic theater 8-track) */
};

with support until 8 channels, and the same matrix in oggenc2.85srcs is only for 6 channels:

CODE

static int wav_permute_matrix[6][6] =
{
    {0},
    {0,1},
    {0,2,1},
    {0,1,2,3},
    {0,2,1,3,4},
    {0,2,1,4,5,3}
};

After vorbis-tools 1.4.0 use the matrix always for wavs until 8 channels:

CODE

        if (wav->channels <= 8)
            /* Where we know the mappings, use them. */
            memcpy(wav->channel_permute, wav_permute_matrix[wav->channels-1],
                    sizeof(int) * wav->channels);
        else
            /* Use a default 1-1 mapping */
            for (i=0; i < wav->channels; i++)
                wav->channel_permute[i] = i;

But oggenc2.85srcs use the matrix only with a few MaskChannel and never if the wav don't have WAVE_FORMAT_EXTENSIBLE header:

CODE

        if (wav->channel_map)
            /* Where we know the mappings, use them. */
            memcpy(wav->channel_permute, wav_permute_matrix[wav->channels-1], sizeof(int) * wav->channels);
        else
            /* Use a default 1-1 mapping */
            for (i=0; i < wav->channels; i++)
                wav->channel_permute[i] = i;

Please, anybody can compile (for windows) vorbis-tools 1.4.0 without changes to test the differences?

[john33]

Actually, it's the source download that hasn't been updated. The compiles use the new channel maps.

Edit: And, the reason the sources haven't been updated is that while the previous versions compiled and ran for 64 bit, the new versions do not. The new versions compile and process FLAC input correctly, but crash on wave input! I will not update the sources until I at least understand why the problem occurs, and hopefully have a resolution.

@Viktor: Although in the oggenc2 sources, the wave file opening and reading routines are changed very little from the previous version, the crash on reading from the wave file occurs without fail. This occurs with the new libvorbis. The new libogg does not cause a problem. What is frustrating is that in the wave file open routines, there are perhaps 6 lines of additional code, the actual wave file read routines are unchanged and it appears to be the reading that causes the problem. As already mentioned, with libvorbis 1.2.3, there is no problem and all works well for 64 bit. I would welcome any comment on this as I am struggling to see where the problem lies. If it's in the new libvorbis, then I don't have the knowledge to deal with it, but unless it's in the initialisation, it seems to occur at the first attempt to read the wave file.

This post has been edited by john33: Mar 28 2010, 20:34

[tebasuna51]

Actually, it's the source download that hasn't been updated. The compiles use the new channel maps.

Maybe, but only for wavs with header WAVE_FORMAT_EXTENSIBLE and some ChannelMask.
The remap must be used for all wav files with less than 9 channels.

BTW, the oggdec in vorbis-tools 1.4.0 have the old remap matrix (only 6 channel) and without WAVE_FORMAT_EXTENSIBLE output, maybe your oggdecV1.9.6 can be improved adding ChannelMask for 6.1 and 7.1 (in audio.c):

CODE

    else if (aufile->channels == 7)
        channelMask = 1807;
    else if (aufile->channels == 8)
        channelMask = 1599;

using this amplied (8x8) remap matrix:

CODE

    int permute[8][8] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,2,1,3,4}, {0,2,1,5,3,4}, {0,2,1,6,5,3,4}, {0,2,1,7,5,6,3,4}};

and permute until 8 channels (instead 6)

CODE

    if (channels > 2 && channels < 9) {

This post has been edited by tebasuna51: Mar 29 2010, 03:40

[john33]

Actually, it's the source download that hasn't been updated. The compiles use the new channel maps.

Maybe, but only for wavs with header WAVE_FORMAT_EXTENSIBLE and some ChannelMask.
The remap must be used for all wav files with less than 9 channels.

I know that's what it says in the Xiph oggenc source, but if the multichannel file has no WAVE_FORMAT_EXTENSIBLE header, remapping the channels makes absolutely no sense as you have no idea what order the channels should be in and any remapping is only a guess that could be completely wrong. If you can convince my I'm wrong about this (other than what it says in Xiph's oggenc) I'm willing to listen, but to remap channels on the basis of a guess seems daft to me. What would make sense would be an option to specify the channel order in the absence of the channel mask being present in the header.

BTW, the oggdec in vorbis-tools 1.4.0 have the old remap matrix (only 6 channel) and without WAVE_FORMAT_EXTENSIBLE output, maybe your oggdecV1.9.6 can be improved adding ChannelMask for 6.1 and 7.1 (in audio.c):

CODE

    else if (aufile->channels == 7)
        channelMask = 1807;
    else if (aufile->channels == 8)
        channelMask = 1599;

using this amplied (8x8) remap matrix:

CODE

    int permute[8][8] = {{0}, {0,1}, {0,2,1}, {0,1,2,3}, {0,2,1,3,4}, {0,2,1,5,3,4}, {0,2,1,6,5,3,4}, {0,2,1,7,5,6,3,4}};

and permute until 8 channels (instead 6)

CODE

    if (channels > 2 && channels < 9) {

Done and I've bumped the version to 1.9.7.

[john33]

Just to add to the 64 bit conundrum, the 64 bit compiles that fail on Windows 7 64 Ultimate, run fine on XP Pro x64! May be that will give someone an extra clue.

[callmeace]

Oggdec download file says v197 , but on rarewares download page it still says v196

On the rarewares index page it announces a v140 build for Vorbis Tools, but I have looked through the site and can't find it!

Have I missed it, or will it be something forthcoming?

Thanks

[john33]

Oggdec download file says v197 , but on rarewares download page it still says v196

Ooops! I forgot to change the heading on the page. Thanks for letting me know, I'll take care of it.

On the rarewares index page it announces a v140 build for Vorbis Tools, but I have looked through the site and can't find it!

Have I missed it, or will it be something forthcoming?

Thanks

Actually, to split hairs, it says 'incorporating'. Some of what is in the vorbis-tools release finds its way into my compiles, but I've never provided a 'vorbis-tools' build, per se, and it won't happen any time soon.

[HotshotGG]

I was able to successfully build the new vorbis-tools packages from the source if anyone has any questions let me know it's tricky, but it's so worth it if you have an older distros like Ubuntu 9.10 and earlier and are stuck in "old synaptic package hell" as I call it ;D. Surprisingly it was the first piece of software that I compiled that actually built correctly, besides writing my own code for the classes I am taking.

This post has been edited by HotshotGG: Mar 29 2010, 23:31

[xiphmont]

I know that's what it says in the Xiph oggenc source, but if the multichannel file has no WAVE_FORMAT_EXTENSIBLE header, remapping the channels makes absolutely no sense as you have no idea what order the channels should be in and any remapping is only a guess that could be completely wrong.

Actually, the Microsoft docs say that if no channel mask is present, the default is all channels are present in order of bitmask. This is definitely what common usage is following.

OTOH, the Microsoft docs also say that > stereo requires WAVE_FORMAT_EXTENSIBLE, but that feels like a retcon. I do know that wav files in the wild quite often just use WAVEFORMATEX for > 2 channels and that's normally handled as if it was WAVE_FORMAT_EXTENSIBLE with a dwChannelMask of 0. In short, follow the default order (L,R,C,LFE,BL,BR,SL,SR...)

This post has been edited by xiphmont: Mar 30 2010, 01:40

[felix26591]

How does libvorbis 1.3.1 compare to aotuv b5.7???