1) The default channel order for input wav (any header) or uncompressed raw data must be FL,FR,FC,LFE,SL,SR
Any other order can optionally be accepted with a new parameter like Aften do:


2) A new parameter must be included to ignore the wav header fields RiffLength and DataLength. This behavior is assumed by recent encoders like:


Reasons:

- The know thread in this forum: http://www.hydrogenaudio.org/forums/index....showtopic=16033

- The most knew free transcoders uses the standard order:
Foobar2000 actually actually produce wrong mapped multichannel ogg files.
AviSynth based (BeHappy, Wavi, ...) need special remapper functions for ogg output.
eac3to, the transcoder for new formats like E-AC3, TrueHD, DTS-HD, also need a extra remap.

- Actually the transcoders send the uncompressed audio data by STDOUT to encoder STDIN with the minimal standard header well know for everybody.
The AudioFormat (int/float), NumChannels, SampleRate and BitDepth is enough (littleendian assumed) to encoder, the WAVE_FORMAT_EXTENSIBLE header can't be required because is less accepted.

- The RAW format is less flexible than standard wav header because we need construct the command line before open the input file.
See this sample:

We don't know is track.thd is 2 or 6 channels, 16 or 24 bits. If we use standard header is really easy.

- For the same reason (STDOUT -> STDIN) the decoder don't know the Datalength until the end of file is reached, but the header must contain this info and is another problem.
If the input file is CBR the datalength (num of samples) can be estimated but is impossible with VBR input without read until eof.
When the output is a file the decoder reopen the file to write the correct header but using STDOUT the RiffLength and DataLength can be corrected.
If exist a method to say the ogg encoder "Ignore these header fields and work like with raw data" the problem is solved.

- With the -ignorelength parameter also the irregular wav files > 4GB can be managed (also a problem for STDOUT).
Is easy than a multichannel wav file reaches this size (83 minutes for a 24 bit, 6 ch, 48 KHz) and can be produced by many soft (Foobar2000, Faad, AviSynth-methods ...).

The issue you describe is not with the Vorbis format itself but with the oggenc application, which has since been fixed in new version 1.2.0. Hope that helps.

Yep is for oggenc2.exe (ogg encoder). If you know where I can post this feature request please say me. Thanks.

And nope, none of them are implemented actually:

1) If you try with a multichannel wav with standar wav header:

oggenc2 -q 5 -o out6.ogg in6.wav
oggdec out6.ogg

you can see the out.wav have different channel mapping than in6.wav.
Only if in6.wav have a WAVE_FORMAT_EXTENSIBLE header work correctly.

2) Of course don't exists a parameter like -ignorelength (at least is not documented), and oggenc2 finish encode when the DataLength (field in wavheader) is reached. We have two problems:

- Wav files greater than 4 GB can't be used because oggenc2 can only encode the first 1:02:08.270 from a 32 bit, 48000 Hz, 6 channel wav.

- When we encode using STDOUT -> STDIN the datalength can't be know until the input stream finish, but the header with SampleRate, BitDepth and Numchannel is enough to begin the encoder until the end of input stream is reached.

I'll look at this next week.

Seems very busy with the new release but maybe this is a time for a few comments about my feature request.

I read the sourcecode in recent vorbis-tools-1.2.0.7z and your code in oggenc2.85srcs.zip and, of course, I see your code is more advanced (WAVE_FORMAT_EXTENSIBLE, 32 int, wrong channel mapping matrix, others formats, ...), then I will try persuade you about this little changes.

1) A new parameter for instance with NeroAacEnc style (in oggenc.c):



2) Changes in wav_open subroutine (audio.c) like:



I think all your code related to channel_map is useless if we can't include the info inside the ogg format. If only one channel map is allowed for a number of channels is better ignore the channelmask in WAVE_FORMAT_EXTENSIBLE until the ogg specs support this issue.

Of course you can put other parameter for the channel mapping like I put in my first post and change the permute_matrix but I prefer:
"* Please, if you have a program that's creating wav channel order other than FL, FR, FC, LFE, BL, BR, report a bug to the author."

tebasuna51, is that a patch for vorbis-tools? If so, could you please post it at the Xiph Trac as a diff attachment? It would be much appreciated.

There are changes for audio.c and oggenc.c from oggenc2.85srcs.zip (John33 in RareWares), the same files in vorbis-tools-1.2.0.7z are very different. But I try tomorrow.

Sorry, I'm new in Vorbis soft and don't know for what there are different sources.

Ignorance is only a problem when one wants to be stubborn and stick to the wrong ideas. Making questions is a good thing, so no need for apologies.

The data in the .7z file announced here is from the official tree. John supposedly makes some changes to the rarewares offerings. Rarewares is mostly a provider for Windows binaries of different audio software and libraries. So when you see differences between the official release and the rarewares release is likely something to make it work better in Windows.

Patches

Include oggenc2_mch.patch with the changes for audio.c, encode.h and oggenc.c from oggenc2.85srcs

Also there are vorbis120.patch with equivalent changes (I hope) to vorbis-tools-1.2.0\oggenc files.
This one also include support for int 32 bits wav's (I use the john33 code ) and WAVE_FORMAT_EXTENSIBLE headers (without channelmask support)

I don't use SVN then the patches are made with WinMerge over fictitious folders.

Well, I 'Add a Ticket' to Xiph Trac with the vorbis120.patch.
But, there are a lot of pending tickets!

@Saoshyant, if you have any influence in Xiph Trac maybe you can do anything because:

1) Major bug remapping 5.1 files. With actual oggenc we need a wav with the channel order:
FL,FR,C,BR,LFE,BL
to obtain a correct mapped ogg. I don't know any soft than output this order. Maybe we need WaveWizard with a new channel mapping each time we need encode a 5.1

2) Support WAVE_FORMAT_EXTENSIBLE wav header. Is so easy!. Only this line and supported:
if (format.format==0xfffe && len>25) format.format=READ_U16_LE(buf+24);

3) --ignorelength. I know introduce a new parameter is hard, but if Aften (ac3) and NeroAacEnc (aac/mp4) do ...

@john33, I like much more oggenn2 (standalone, correct mapping if WAVE_FORMAT_EXTENSIBLE, int 32 support, ...), please, forget read channelmask if you can't pass the value to the encoded ogg.

To support WAVE_FORMAT_EXTENSIBLE is enough 2) and remap all the same with {0,2,1,4,5,3}

And another please, is easy for you, --ignorelength or --readtoeof or --untileof (to be ogg original) ...

The correct remap and --untileof are vital for Foobar2000 'convert'.

I'm interested because I want make a new BeHappy release (audio transcoder bassed in AviSynth).
Actually I recommend oggenc2 v2.84 and use a internal remap and raw output to avoid the datalength limit, but I hope recommend oggenc2 v2.86 and change the method like other modern encoders do.

Last question (I promise: this is my last post without answer):
Can wait to recommend v2.86?

Edit: The "Multichannel code improved" announced need these features.

Yes, I noticed. Thank you. The patch will be tested and part or all of it will be applied.

Tell me just one thing: is that really the correct way to handle the 5.1 channel mapping? Have you tested Vorbis files with that kind of mapping and had them working on players that support 5.1?



Just like in any other bug tracker. The only real concern here are the XiphQT tickets, which no longer have anyone to deal with them.

Yes, oggenc2 by John33 do this remap with wav files WAVE_FORMAT_EXTENSIBLE (must be with all) and play /decode fine with Foobar2000, MPC, VLC, Bass, ffdshow, ...

Saoshyant ask me, by PM, for a better explanation of the changes in my suggested patches.
Like there are issues commons to oggenc and oggenc2 I think is better use this thread and everybody can know my arguments and see the differences between the two encoders.
First of all is define the problems and know if there are will of change.

1) Channel Mapping problem.
Different in oggenc/oggenc2

1.1) Channel Mapping bug in oggenc (correct in oggenc2)
The wav_permute_matrix elements:

1.1.a) {0,1,2,3,4}, /* No equivalent in wav? */
The default in wav format must be FrontLeft,FrontRight,FrontCenter,BackLeft,BackRight (5.0) with MaskChannel 0x0037.
Is the default also in Flac and can be a normal upmix from a stereo DolbyProLogic II encoded. When do upmix, the LowFrequencyeffects isn't needed, the low frequencies extraction can be done by the hardware player.
Then here we need permute the FR with the FC only:
{0,2,1,3,4},

1.1.b) {0,2,1,5,3,4}
Here the permute between FR <-> FC is ok, but the 3 last are wrong, are used with:
memcpy(wav->channel_permute, wav_permute_matrix[wav->channels-1], sizeof(int) * wav->channels);
...
buffer[j][i] = buf[i*f->channels + f->channel_permute[j]];
and the effect is inverse to desired, the FL,FR,FC,LF,BL,BR input channels are permuted to FL,FC,FR,BR,LF,BL
To obtain FL,FC,FR,BL,BR,LF must be:
{0,2,1,4,5,3}

1.2) Channel Mapping discrimination in oggenc2 (correct in oggenc)
The precedent permute matrix are applied always in oggenc, but in oggenc2 are only applied if the input data have a WAVE_FORMAT_EXTENSIBLE header (WFE henceforth).
If the input data are raw or with standard header no channel mapping is applied. Like standard wav and raw data have the same channel order than WFE these ogg files have a wrong mapped.
Solution: the permute matrix must be applied always.

2) MaskChannel support
In precedent point we know the channel order in uncompressed audio data: FL,FR,FC,LF,BL,BR but not always are all present.
To difference a 4.1 (FL,FR,LF,BL,BR) from a 5.0 (FL,FR,FC,BL,BR) the WFE header include the MaskChannel field.
This info do not exist in ogg structure then is a big problem to solve.
The same problem have Flac.

Then only a default ChannelMasK for each channel number are allowed. How are supported by oggenc/oggenc2?

2.1) Oggenc don't accept WFE headers then never can manage MaskChannel.
First we need accept WFE, instead validate only the 'fmt ' chunk length:
if(len!=16 && len!=18)
we need:
if(len!=16 && len!=18 && len!=40)
because WFE have more data in 'fmt ' chunk, and we need read
if (format.format == 0xfffe && len = 40)
format.format = READ_U16_LE(buf+24);
because the real data format (int or float) is in a new position in WFE, (the WFE is identified by format == 0xfffe && len = 40).
And if we want manage the channel mask maybe we want read (like in oggenc2):
format.channel_mask = READ_U32_LE(buf+20);
There are other cosmetic changes in the patch but it is the basic to support WFE.

2.2) Oggenc2 accept WFE headers and validate the MaskChannel.
All work fine if the MaskChannel match with the accepted default.
But if don't match, for instance a 4.1, is treated like a standard wav, not remapped then always with wrong channelmap.
I think we can, or ignore the MaskChannel or reject the not allowed (like Flac do).

3) Input data > 4 GB
This is usual with multichannel movies audio tracks.
Here the behaviour is the same for oggenc/oggenc2.

3.a) The piped Raw method works fine (is the method used in BeHappy).

3.b) The wav/aiff files >4GB never are correct because there are fields to short (4 bytes) to store the file or datalength.
There are decoders/audiosoft (Faad, Foobar2000, BeHappy, ...) that can output this irregular wav files but the encoders must be instructed to ignore this fields and read audio data until the end of the file:
Aften (ac3 encoder): -readtoeof 1
NeroAacEnc (aac): -ignorelength
Flac with v1.2.1 have a undocumented parameter --ignore-chunk-sizes but still don't work properly


Then I propose a new parameter for oggenc/oggenc2, and, if present, the soft must work like with raw data.

3.c) The correct way for the future is support new uncompressed formats like w64 and RF64 obviously without the 4 GB limit.

4) A --untileof (for instance) parameter for oggenc/oggenc2 can be usefull, not only for irregular files >4GB, but also when the audio data is piped to the encoder and the final size is unknow.
The more simple way to send the necesary parameters to begin the encode (like the raw parameters: --raw-format, --raw-bits, --raw-chan, --raw-rate), is construct a incomplete header.

Any comments?

Tebasuna, I have good news: your patch has been approved. There's just a little something to considere, which is --ignorelength. Would there be problems if this was the default instead of an option? And if not, can you revise your patch accordingly?

Thanks for the news Saoshyant.

There are a problem if always ignore the datachunk size and read like audio data until end of file.
Is legal add extrachunks after the datachunk. In old Golwave versions the cue points was added after the audio data. Now WavoSaur write info at end of file also.

The --ignorelength parameter is a exception to solve a problem until formats like w64 or rf64 are more extended.

For those not following, everything in the patch has been committed. Expect to see the new features in the next release of vorbis-tools.

Good news!. Thanks Saoshyan.

I hope John33 make the same with oggenc2.



Seems a very long week.