ac3, nicac3source and ffdshow

[d2mp]

I've been using nicac3source for processing ac3 audio files in avisynth (ssrc, framerate conversion, normalization, and so on).
Some ac3 files are being reported as bad with nicac3source, but with directshowsource (ffdshow is installed) are working well.

For using directshowsource, I want to be sure that ffdshow is being used WITHOUT downsampling.
Of course I can configure my PC to make sure that the default preset of ffdshowaudio respect this, and remove every other ac3 codec (like ac3filter).

But, These avs scripts are going to be used in several PC's.
I can confirm that ffdshow is installed, but I cannot be sure that there is no other codec installed in the system, with higher priority than ffdshow, or if ffdshow is well configured.

So, I ask help for:

a) How to force ffdshow liba52 ac3 codec to be the higher priority Ac3 codec in a system ? or using ffdshowaudio() is enough to garantee it is the one ?

b) How to force ffdshowaudio() to always output ac3 WITHOUT DOWNSAMPLE (mantain the original number of channels) ?.

Thank you ver much
D2mp
http://d2mp.planetaclix.pt

[tebasuna51]

I agree with all the problems about DirectShowSource and haven't answers to your questions, but you can try the last NicAudio.dll (http://nic.dnsalias.com/NicAudio_alpha3.zip)

There are "streaming" ac3 with a mix of frames 2.0 and 5.1, with precedents versions of NicAudio crash, now fill with silence the second type of frames found.

[Wilbert]

or using ffdshowaudio() is enough to garantee it is the one ?
Yup.

You can always make a graph manually and open that with DSS if you don't want to mess with the merits of the AC3 decoders.

[d2mp]

I agree with all the problems about DirectShowSource and haven't answers to your questions, but you can try the last NicAudio.dll (http://nic.dnsalias.com/NicAudio_alpha3.zip)

There are "streaming" ac3 with a mix of frames 2.0 and 5.1, with precedents versions of NicAudio crash, now fill with silence the second type of frames found.

It works! Thank you very much.

By the way, I've done several testings with ffdshowaudio, and it seems that if the function is called in avisynth, it will "force" the usage of ffdshow audio codecs.
This is good, because it is possible to force a lot of ffdshow audio options.
But there is still a problem: In some systems, the usage of ffdshowaudio( ) in avisynth crashes ffmpeg.
Any ideias ?


Thanks
d2mp
http://d2mp.planetaclix.pt

[Wilbert]

@tebasuna51,

Is this the last version of NicAudio?

If i try to open a 96kHz, 24bit, 2ch lpcm with it, it's opened as integer 32 bit accordingly to Info(). Could you or Nic fix that?

[tebasuna51]

Is this the last version of NicAudio?

You have NicAudio v1.7 AviSynth 2.5 AC3/MPA/LPCM/DTS Decoder (http://nic.dnsalias.com/NicAudio.zip) with sources and Readme.txt, but the dll is the same than here.

If i try to open a 96kHz, 24bit, 2ch lpcm with it, it's opened as integer 32 bit accordingly to Info().

Is true, 20 and 24 bits are treated like 32 int in m2audio_lpcm.cpp
switch (InQuant)
{
// 16 bit
case 16:
Quant = InQuant;
Info.sample_type = SAMPLE_INT16;
break;

// 20 & 24 bit
case 20:
case 24:
case 32:
Quant = 32;
Info.sample_type = SAMPLE_INT32;
break;
...

Could you or Nic fix that?

Sorry, maybe Nic, I'm still learning how compile AviSynth plugins, and don't know lpcm files.

[IanB]

If i try to open a 96kHz, 24bit, 2ch lpcm with it, it's opened as integer 32 bit accordingly to Info(). Could you or Nic fix that?So he kindly unpacks your source to 32 bit int (floats would have been more useful). Is the unpack done incorrectly? :confused: What is to fix?

If you want it packed for output add a ConvertAudioTo24bit() to the end of your script.

[Ebobtron]

(floats would have been more useful)

Outputs 32 float for me :)

[tebasuna51]

@Ebobtron
The NicLPCMSource("c:\File.lpcm", 96000, 24, 2) output is 32 int but if you make any operation with the audio AviSynth can convert the samples to 32 float automatically.

@IanB
I think the goal is obtain a bit identical (with big-endian translated to little-endian) wav 24 bits int, to be translated to Flac for instance, without the extra 8 bits.

Maybe with a real sample I can make test because using:

NicLPCMSource("d:\garbage.lpcm", 48000, 24, 2)
ConvertAudioTo24bit()

and

sox.exe -B -r48000 -t .raw -c 2 -3 -s "d:\garbage.lpcm" St24sox.wav

i obtain different output and don't know what is the correct (if any).

[Wilbert]

As tebasuna51 says. I'm not sure whether the unpack is done incorrectly.

I think the goal is obtain a bit identical (with big-endian translated to little-endian) wav 24 bits int
A few questions about this endian stuff (which i always wanted to ask some day). Why is this an issue in the audio world, and not in the video world? Is lpcm always big-endian? Why should flac be little-endian, or doesn't it matter much? As i understand it, both big- and little-endian means that your audio samples are reordered. How does your audio-player reorders the samples back for playback?

[Nic]

Wilbert PM'd me to have a look saying:
24 bit lpcm is opened as 32 bit. Is this done correctly? If i use ConvertAudioTo24Bit afterwards, do i get bit identical output as when opening it as 24 bit directly?

I've never been too knowledgeable about LPCM because I think I only own one DVD that uses it (AFAIK)!

NicAudio always converts internally to 32 bit for 24bit audio. The conversion is lossless (just putting 0 in the 4th byte). However, I believe (and please check) that ConvertAudioTo24bit converts to float before converting to 24bit. Is this operation lossless? This might be causing the difference when using sox.

NicAudio could probably be easily made to output 24bit audio for 24bit files, if necessary, but is it? The extra 8 bits shouldn't make a difference to FLAC compression.

-Nic

[Leak]

The conversion is lossless (just putting 0 in the 4th byte).
Actually, I'd call that "almost lossless" - you're not mapping the 24 bit min/max values to the 32 bit min/max values, so for example clipping them in a filter will yield a slight difference.

Using the 8 bits below the sign bit as filler material yields a closer match, and it's still going to yield the same result if you just chop off the lowermost byte for 32->24 bit conversion.

np: Pan Sonic - Pakoisvoima / Fugalforce (Kesto (234.48:4) (Disc 1))

[tebasuna51]

Making a test with identifiable bytes:

Data test (ordered bytes)

01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20

Sox 16 bits (ok)

02 01 04 03 06 05 08 07 0A 09 0C 0B 0E 0D 10 0F
12 11 14 13 16 15 18 17 1A 19 1C 1B 1E 1D 20 1F

Sox 24 bits (ok)

03 02 01 06 05 04 09 08 07 0C 0B 0A 0F 0E 0D 12
11 10 15 14 13 18 17 16 1B 1A 19 1E 1D 1C 21 20

Sox 32 bits (ok)

04 03 02 01 08 07 06 05 0C 0B 0A 09 10 0F 0E 0D
14 13 12 11 18 17 16 15 1C 1B 1A 19 20 1F 1E 1D

Nic 16 bits (ok)

02 01 04 03 06 05 08 07 0A 09 0C 0B 0E 0D 10 0F
12 11 14 13 16 15 18 17 1A 19 1C 1B 1E 1D 20 1F

Nic 24 bits but 32 output

00 09 02 01 00 0A 04 03 00 0B 06 05 00 0C 08 07
00 15 0E 0D 00 16 10 0F 00 17 12 11 00 18 14 13
00 21 1A 19 00 22 1C 1B 00 23 1E 1D 00 24 20 1F

Nic 24 bits without the 00 bytes (wrong)

09 02 01 0A 04 03 0B 06 05 0C 08 07 15 0E 0D 16
10 0F 17 12 11 18 14 13 21 1A 19 22 1C 1B 23 1E

Nic 32 bits (broken)

78 01 31 01 08 AA 31 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Seems NicAudio only work for LPCM 16 bits, the output for 24 or 32 bits is broken.

[Nic]

Hi tebasuna51:

Do the files sounds very different?

When I try sox with your parameters I get errors for -B and -3.

Could you tell me how you did your tests exactly and I'll replicate it and fix any issues.

-Nic

[Nic]

http://nic.dnsalias.com/NicAudio.zip

This new version should give 24 bit output for 24 bit stereo or mono files. Also adds support for 24 bit LPCM wav files and fixes a bug with wav file support (where I didn't skip the wav header).

-Nic

[tebasuna51]

http://nic.dnsalias.com/NicAudio.zip

This new version should give 24 bit output for 24 bit stereo or mono files.

Don't work for me, still 32 bit output now with zeroes at end of file then the samples are mixed.

Checking m2audio_lpcm.cpp maybe:
-----------------------------------------
// Constructor
m2AudioLPCMSource

1) The switch (InQuant) in line 98 must be after the switch (InChannelCount), you use a:
if (ChannelCount != InChannelCount || InChannelCount > 2 )
before the ChannelCount and InChannelCount variables are defined.

-----------------------------------------
bool m2AudioLPCMSource::ReadFrame()

2) Don't exist case 32 when big-endian are converted to little-endian, then 32 bits are not supported.

3) The conversion big-endian -> little-endian applied to 24 bits is:

for (i = 0; i < FrameLength; i += 6 * InChannelCount)
...
PCM_Buffer[0] = Input[i+ 8];
PCM_Buffer[1] = Input[i+ 1];
PCM_Buffer[2] = Input[i+ 0];
PCM_Buffer[3] = Input[i+ 9];
PCM_Buffer[4] = Input[i+ 3];
PCM_Buffer[5] = Input[i+ 2];
PCM_Buffer[6] = Input[i+10];
PCM_Buffer[7] = Input[i+ 5];
PCM_Buffer[8] = Input[i+ 4];
PCM_Buffer[9] = Input[i+11];
PCM_Buffer[10] = Input[i+ 7];
PCM_Buffer[11] = Input[i+ 6];

3-1) For what two blocks (12 bytes) instead one (6 bytes)?
3-2) Of course don't match with sox method, maybe the conversion must be:

for (i = 0; i < FrameLength; i += 3 * InChannelCount)
...
PCM_Buffer[0] = Input[i+ 2];
PCM_Buffer[1] = Input[i+ 1];
PCM_Buffer[2] = Input[i+ 0];
PCM_Buffer[3] = Input[i+ 5];
PCM_Buffer[4] = Input[i+ 4];
PCM_Buffer[5] = Input[i+ 3];

[IanB]

@Nic,

I am not sure your original code was that wrong, but you seem to have some holes (absent code paths) in the logic. It is extremely difficult to tell if the extra data beyond 16bits is correct. You need high grade audio equipment and pristine hearing with suitable material to be able to tell. Reverse enginnering is always difficult.

@tebasuna51,

I think there is something missing from you table, the number of channels (N==1 ?). This effects the packing of the 16bit primary samples with the auxilary data.

@All,

It seems that the DVD engineers have a Motorola mindset and they want data mostly in 32bit units. From my limited research the packing layout appear to be 2 times the number of channels as 16 bits samples in channels order, followed by auxilary precision as bytes for 24bit or nibbles for 20 bit, again in channel order. All this complicated packing seems to be so that 16bit samples can be easily plucked out on cheaper hardware.

Legend:-
[Sn] - High byte sample n, ie S0
[sn] - Low byte sample n, ie s1
[an] - Auxilary precision bits sample n, ie a0
[xSn] - Channel x sample, ie rS0, right sample 0 high byte

Thus 24bit mono on the disk should be 6 byte units
. [S0][s0][S1][s1][a0][a1]
needing to be unpacked to 32bit intel format as
. [00][a0][s0][S0] [00][a1][s1][S1].
or needing to be unpacked to 24bit Windows format as
. [a0][s0][S0] [a1][s1][S1].

24bit stereo on the disk should be 12 byte units
. [lS0][ls0][rS0][rs0][lS1][ls1][rS1][rs1][la0][ra0][la1][ra1]
needing to be unpacked to 32 bit intel format as
. [00][la0][ls0][lS0] [00][ra0][rs0][rS0] [00][la1][ls1][lS1] [00][ra1][rs1][rS1]
or needing to be unpacked to 24bit Windows format as
. [la0][ls0][lS0] [ra0][rs0][rS0] [la1][ls1][lS1] [ra1][rs1][rS1].

And likewise 20bit stereo on the disk should be 10 byte units
. [lS0][ls0][rS0][rs0][lS1][ls1][rS1][rs1][la0|ra0][la1|ra1]
needing to be unpacked to 32bit intel format as
. [00][la0|0][ls0][lS0] [00][ra0|0][rs0][rS0] [00][la1|0][ls1][lS1] [00][ra1|0][rs1][rS1].
or needing to be unpacked to 24bit Windows format as
. [la0|0][ls0][lS0] [ra0|0][rs0][rS0] [la1|0][ls1][lS1] [ra1|0][rs1][rS1].

By extension 24bit 3 channel, [abc], on the disk should be 18 byte units
. [aS0][as0][bS0][bs0][cS0][cs0][aS1][as1][bS1][bs1][cS1][cs1][aa0][ba0][ca0][aa1][ba1][ca1]
needing to be unpacked to 32 bit intel format as
. [00][aa0][as0][aS0] [00][ba0][bs0][bS0] [00][ca0][cs0][cS0] [00][aa1][as1][aS1] [00][ba1][bs1][bS1] [00][ca1][cs1][cS1].
or needing to be unpacked to 24bit Windows format as
. [aa0][as0][aS0] [ba0][bs0][bS0] [ca0][cs0][cS0] [aa1][as1][aS1] [ba1][bs1][bS1] [ca1][cs1][cS1].
And what indeed is the 3 channel order? Left, Right, Centre ??? :confused:

Can anyone confirm my suposition here?

:Edit: Fix ?S1 -> ?S0 editing snafu (thx tebasuna51)
:Edit: Add legend and 24bit windows format decoding examples.

[tebasuna51]

@tebasuna51,

I think there is something missing from you table, the number of channels. This effects the packing of the 16bit primary samples with the auxilary data.
Nope, I only test 2 channel 24 bits.
The complete code is
for (i = 0; i < FrameLength; i += 6 * InChannelCount) {
switch ( InChannelCount ) }
case 2:
PCM_Buffer[0] = Input[i+ 2];
PCM_Buffer[1] = Input[i+ 1];
PCM_Buffer[2] = Input[i+ 0];
...
It seems that the DVD engineers have a Motorola mindset and they want data mostly in 32bit units. From my limited research the packing layout appear to be 2 times the number of channels as 16 bits samples in channels order, followed by auxilary precision as bytes for 24bit or nibbles for 20 bit, again in channel order. All this complicated packing seems to be so that 16bit samples can be easily plucked out on cheaper hardware.

If you are rigth then is not a big-endian -> little-endian but other specific order and Sox can't be used to transcode LPCM to PCM wav.

Talking only about 24 bit stereo your order (with 2 corrections)

[lS0][ls0][rS0][rs0][lS1][ls1][rS1][rs1][la0][ra0][la1][ra1]
can be unpacked to 24 bit for PCM wav
[la0][ls0][lS0][ra0][rs0][rS0][la1][ls1][lS1][ra1][rs1][rS1]

And is exact to the Nic routine.

[Nic]

Hi,

Thanks for the input/discussion and picking up that bug:
http://nic.dnsalias.com/NicAudio.zip will now output 24 bit audio.

The mapping I am doing when reading Wav LPCM files come directly from DGIndex as that only saves LPCM Wav files. Therefore I reverse the logic so that the filter can read it as if the file was a raw LPCM file.

tebasuna51: When I try to make a wav file using sox all it does is put a Wav header on the file rather than any proper conversion. But maybe I'm using it wrong.

IanB: I'm missing code paths in the sense I'm supporting only a subset of what I could support. Or are there more severe code paths missing?

Cheers,
-Nic

[tebasuna51]

@Nic
Thanks, now NicLPCMSource("d:\some.lpcm", 48000, 24, 2) output 24 bit samples.

@Wilbert
Please, can you confirm if now you obtain a correct conversion from raw lpcm to wav?

If so please forget all my comments about big-little endians, the first thing i say is: "don't know lpcm files" (http://forum.doom9.org/showthread.php?p=1033005#post1033005)

[Wilbert]

Thanks Nic!

@Wilbert
Please, can you confirm if now you obtain a correct conversion from raw lpcm to wav?
Perhaps a dumb question. But, how exactly?

Thus 24bit mono on the disk should be 6 byte units
[S0][s0][S1][s1][a0][a1]
Another dumb question. What do the letters S,s,a,0,1 stand for? Why is it 6 bytes instead of 3?

I'm feeling a bit uncomfortable with this stuff. If i understand it correctly, there are different byte orderings (lpcm of DVD is one; if you got your lpcm from some other source, probably some other). So, if you don't know were your lpcm came from, you can't convert it properly? That can't be right ...

[tebasuna51]

@Wilbert
Please, can you confirm if now you obtain a correct conversion from raw lpcm to wav?
Perhaps a dumb question. But, how exactly?


If the output play correctly (or send a sample to verify NicLPCMSource).

[IanB]

@tebasuna51, (1), thanx I fixed my post (S1->S0)'s

@Nic, You probably stop most of the unsupported cases in the constructor, but the code might fall thru unexpectably if you have not. I think mythical 32bit input leaked thru this way.

@Wilbert, Well that is the question under my post, "Is packing genericly done at 2 times channel count?" I have edited a legend into my post. And "Why is it 6 bytes instead of 3?" I was guessing "Motorola thinking" and I am looking for support or denial plus references for this premise.

@tebasuna51, (2), "Perhaps a dumb question. But, how exactly?" And as I sort of said in my previous post, having got the high 16bits decoded correctly and in the right order it will be extremely difficult to hear if the auxilary precision bits have been done correctly. The effect of these bits is less than some -90db, i.e. "high grade audio equipment and pristine hearing with suitable material". Anybody got a 24bit test DVD with -80dbm pure sine tones.

[Wilbert]

Some stuff about multichannel lpcm from the ffmpeg dev list:


(...)

Also, I finally figured out how the channels are stored in LPCM. Pretty smart
actually, mainly putting it here so it's documented somewhere :).

LPCM stores the 16msb's of the first two samples for each channel first, then
appended to the end of this is the 8 (or 4)lsb for each of the previous channels.

eg: (4 channel 24bit) :
16msb of L1, R1, SL1, SR1, L2, R2, SL2, SR2. ( 2 * 4 * 16/8 = 16 bytes )
then
8lsb of L1, R1, SL1, SR1, L2, R2, SL2, SR2. ( 2 * 4 * 8/8 = 8 bytes )

eg: (3 channel, 20bit) :
16msb of L1, R1, C1, L2, R2, C2. ( 2 * 3 * 16/8 = 12 bytes )
then
4lsb of L1, R1, C1, L2, R2, C2. ( 2 * 3 * 4/8 = 3 bytes )

A player wich only can handle 16bit, can then easily just ditch all of the lsb
data and use the 16msb bits that comes first wich, has been noticed before, is
in bigendian byteorder.


Joakim
source: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-March/026085.html

[Wilbert]

@tebasuna51, (2), "Perhaps a dumb question. But, how exactly?" And as I sort of said in my previous post, having got the high 16bits decoded correctly and in the right order it will be extremely difficult to hear if the auxilary precision bits have been done correctly. The effect of these bits is less than some -90db, i.e. "high grade audio equipment and pristine hearing with suitable material". Anybody got a 24bit test DVD with -80dbm pure sine tones.
On rarewares there is a utility (OS) called "LPCM 24bit processor (http://www.rarewares.org/others.php)", which decodes the LPCM to standard 24bit WAV. Perhaps anyone of you can check whether the decoding is done in the same way.

@Wilbert, Well that is the question under my post, "Is packing genericly done at 2 times channel count?" I have edited a legend into my post. And "Why is it 6 bytes instead of 3?" I was guessing "Motorola thinking" and I am looking for support or denial plus references for this premise.
3 bytes is only for mono 24 bit LPCM :) Anyway wiki.multimedia.cx (http://wiki.multimedia.cx/index.php?title=PCM) seems to agree with this, but of course, they don't give any references.

[tebasuna51]

On rarewares there is a utility (OS) called "LPCM 24bit processor (http://www.rarewares.org/others.php)", which decodes the LPCM to standard 24bit WAV. Perhaps anyone of you can check whether the decoding is done in the same way.

Yes, I found also this utility and have exactly the same algorithm than NicLPCM and reflected in IanB post.

[IanB]

Ah! It feels good when the open source community pulls together all the fragments of a spec.

[IanB]

I had a need for a fully functional NicLPCMSource so I have done a pass thru m2audio_lpcm.cpp to remove some restrictions and generalize the code. I also raid'd a few minor bugs. It now passes back all the available channels into avisynth as 24bit integer for 20 and 24 bit sources.

Get it here NicAudio_20070821.zip (http://avisynth2.sourceforge.net/NicAudio_20070821.zip). Please test and comment here.

[tebasuna51]

I had a need for a fully functional NicLPCMSource so I have done a pass thru m2audio_lpcm.cpp to remove some restrictions and generalize the code. I also raid'd a few minor bugs. It now passes back all the available channels into avisynth as 24bit integer for 20 and 24 bit sources.
Please test and comment here.

I can't test because I haven't true LPCM sources, but reading the code:

- "/* bah humbug, give all the channels to AVS!"
I agree AVS have methods to select, delete or add empty channels.

- Of course never 24 bits are converted to 32
InChannelCount = Channels;
...
ChannelCount = InChannelCount;
...
switch (InQuant) {
...
case 24:
if ( InChannelCount != Channels )
{
// If were converting the number of channels do it in 32 bit
Quant = 32;
Info.sample_type = SAMPLE_INT32;
}
else
...
And so always:
Quant = InQuant;
Only raw InQuant = 20 -> Quant = 24
Others than 16, 20 raw, 24, 32 are rejected.

- And never need AuxBuffer2:
if (ChannelCount != InChannelCount) {
AuxBuffer2Size = (SamplesPerFrame * ChannelCount * Quant) / 8;
AuxBuffer2 = new unsigned char[AuxBuffer2Size];
}


- In first part of ReadFrame() there are many options impossible:
switch (InQuant) {
case 20:
if ( bIsWavFile ) // Impossible
switch (Quant) {
case 24: // Convert to 24 bit. Only possible
...
case 32: // Impossible
default: // Impossible
case 24:
switch (Quant) {
case 24: // Convert to 24 bit. Only possible
...
case 32: // Impossible
default: // Impossible
case 32: // I don't know if exist but we need the case, before is a bug

- And never can use the last part of ReadFrame()
// Check if we have to adjust the channel configuration
if (AuxBuffer2)
...

- In GetAudio I need learn your:
//Code to prohibit illegal audio requests. Init buffer in that case

- When a header is detected (bIsWavFile==true) no translation is done then I supose is standard wav PCM files instead LPCM.
Here I have some questions:
1) The wav header are not read then the output can be unpredictable.
2) The Header Size is supposed 44 bytes but is not always this.
3) Without channels changes is not useful open wav's with NicLPCMSource()

I'm working about open wav files with a plugin instead WavSource() and here are some desired issues:

- Open wav's with WAVE_FORMAT_EXTENSIBLE header.
- Open w64 files.
- Open raw PCM files.
- Open standard wav PCM files > 4 GB.

Using a modified m2audio_lpcm.cpp and AudioHeader.h I make a new m2audio_rawav.cpp and with C++ 2005 Express a RaWav.dll
to open these kind of files with RaWavSource()

I'm sure the code can be optimized because I'm not a expert in C++, but if we seems is a interesting feature can be included in NicAudio. Reading the sourcecode you can see the idea.

Here is (http://www.mytempdir.com/2005910).

BTW, @IanB, to support WAVE_FORMAT_EXTENSIBLE (2.5.8) or any kind of multichannel, maybe we need a new audio property: MaskChannel.

For instance NicAc3Source need inform to AVS the AcMod and LFE presence and can be made with a Info.MaskChannel.

[IanB]

@tebasuna51,

Yes there is now lots of dead code, I don't delete code in guest mode ;). I have fleshed in the holes at the lower levels and adjusted the upper levels to suit what I needed. If I was seriously going to change things I would have added options to control 24/32bit output and channel masking/spoofing. The option is still available, Nic's code, Nic's choice.

I was a little confused by the bIsWavFile stuff here, I think it only confuses the code and a separate new "NicRIFFSource" would be a better place for it. i.e. Keep the LPCM code pure LPCM.

And Yes if reading files with a header, then the header should be passed and obeyed, not just skip 44 bytes.

- Open wav's with WAVE_FORMAT_EXTENSIBLE header.From 2.5.8 WavSource does this.
- Open w64 files.Yes a W64Source would be very useful.
- Open raw PCM files.NicRawPCMSource already does this, it needs some endian and skip header options.
- Open standard wav PCM files > 4 GB.Standard RIFF wav files cannot exceed 4Gb. There are hacks around. Have a look at what Avery is doing in VDub source.
MaskChannelThe jury is still out on what to do about this. Adding it to VideoInfo implies many things. There are thoughts outstanding on per clip arbitary properties, perhaps this is a case in point.

[tebasuna51]

NicRawPCMSource already does this, it needs some endian and skip header options.
I don't see this new option in mpasource.cpp :eek: , I look only the lpcm file.

Maybe wav > 4GB are not standard, but raw files don't have any limit and NicRawPCMSource can't read files > 4GB.

Really is more simple than my first solution. Here is a new one (http://www.mytempdir.com/2006146), to read raw, wav, w64 > 4GB (or not).

[Nic]

Nic's code, Nic's choice
Do whatever you want with the code :) Work takes up most my time and I don't have much in the way of LPCM files and therefore little motivation in this area.

Good luck :)

-Nic

[tebasuna51]

I'm trying compile nicaudio.dll with Visual C++ 2005 Express and after the conversion to the new C++ version and a lot of 'Warnings' I get a:

fatal error LNK1181: cannot open input file '.\Release\layer31.obj'

There are mpg123\layer3_.c and others but not a layer31. What is the problem?

BTW, a new version of RaWav.dll (http://www.mytempdir.com/2070490) can open also AU, AIF (>4GB) and the new legal formats for >4 GB: W64, RF64 and CAF.

[tebasuna51]

Do whatever you want with the code :) Work takes up most my time and I don't have much in the way of LPCM files and therefore little motivation in this area.

Good luck :)

-Nic

If is ok for everybody I want continue developing this tool in CodePlex, near BeHappy project (http://www.codeplex.com/BeHappy).

At this moment I have some improvements:
- AC3:
bugfix with dsurmod (http://forum.doom9.org/showthread.php?p=1071730#post1071730)
bugfix with some acmod values (http://forum.doom9.org/showthread.php?p=977363#post977363)

- MP123:
updated to new version (http://forum.doom9.org/showthread.php?p=1102957#post1102957)

- LPCM:
Bugfix when (always for me) count > Left.
Another endian-remap mode to support BluRay lpcm.

- RAWAV:
Included the support for many uncompressed formats WAVE_FORMAT_EXTENSIBLE, W64, ...

And support for >4 GB in all input files.

I want continue using the NicAudio name for compatibility and include new decoders for aac, m4a, eac3, mlp, TrueHD, ...

No problem?