Aften 0.0.8 is out

[shae]

Using Kurtnoise's compile of 0.06 (2/2/2006, the directory in the ZIP is called rev304+, the EXE just says "Version SVN"), I found a potential problem.

The number of samples I encoded was an exact multiple of the AC3 frame (1536), but the output AC3 had one extra frame.

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).

[jruggle]

Using Kurtnoise's compile of 0.06 (2/2/2006, the directory in the ZIP is called rev304+, the EXE just says "Version SVN"), I found a potential problem.

The number of samples I encoded was an exact multiple of the AC3 frame (1536), but the output AC3 had one extra frame.

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).

It should only be silence (with only small disturbances) at the beginning and end. The silence at the beginning is due to the fact that each input sample is supposed to be represented in 2 consecutive AC3 frames. If this is not done, the audio will not be encoded accurately. The FFmpeg encoder does this as well, and I made a decision to keep it this way. The extra samples at the end are due to the offset at the beginning, which makes the total samples *not* a multiple of 1536 and creates the need for an extra frame, padded with silence.

I was going to reference the aften-devel mailing list archives, but Sourceforge is giving me a server error... so if it ever comes back up, the thread started on 1/14/07 and was titled "samples flushing".

-Justin

[shae]

Can you elaborate on "each sample is supposed to be represented in 2 consecutive frames"? I don't get it. I thought AC3 frames are independent.

What I'm trying to do is local editing of frames in an AC3 stream. After the edit I need the reencode to be positioned accurately so that I can replace only the modified frames. For now I'm just adding 1280 samples at the beginning and ignoring the first and last output frames, but this adds more steps.

While at it... are there any things I should set correctly in order to have the new encoded frames blend in alright (besides bitrate and channel configuration)? Is there a tool that can show the BSI flags, for example? Is there anything else that I should consider?

BTW: Isn't Aften setting the lowpass too agressively? I will have to check again, but I think for 5.1/384kbit it was 14kHz (or maybe 16kHz). The source AC3 has it at 17-18kHz.

[tebasuna51]

I decoded the output AC3 back to WAVs with BeSweet to examine it. I found extra silence, most of it at the end, some at the beginning, and also a bit of added non-silence parts.

Is this a bug or is there a hidden way to have no extra output padding, and retain the "timing" of the original WAV input?

Edit: It's 256 extra samples at the beginning and 1280 at end (could be ±1-2).
Is not a bug, result from a dialog between Justin and DarkAvenger in Mailing List (http://sourceforge.net/projects/aften) -> aften-devel -> Topic: samples flushing, between 2007-1-14 and 2007-1-19

All the encoders I know (SoftEncode, Scenarist, ac3enc.dll, aften) make a delay of 256 samples (5.333... ms at 48 KHz). Seems an ac3 requirement. Then, instead cut the last 256 samples (like do SoftEncode and Scenarist), aften include a last frame with the last 256 samples and silence.

Edit: I don't see the Justin answer before.

[jruggle]

Can you elaborate on "each sample is supposed to be represented in 2 consecutive frames"? I don't get it. I thought AC3 frames are independent.
In their encoded state, which is in the frequency domain, each frame is independent, but when decoded into the time domain, the blocks of audio samples are overlapped and added to get the final pcm output. This is a result of the (I)MDCT (http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform) [wikipedia].


What I'm trying to do is local editing of frames in an AC3 stream. After the edit I need the reencode to be positioned accurately so that I can replace only the modified frames. For now I'm just adding 1280 samples at the beginning and ignoring the first and last output frames, but this adds more steps.
Just to be helpful, I've added an option to the commandline to remove the start-of-stream padding. I just committed it to SVN about an hour or so ago. The command option is "-pad 0".


While at it... are there any things I should set correctly in order to have the new encoded frames blend in alright (besides bitrate and channel configuration)? Is there a tool that can show the BSI flags, for example? Is there anything else that I should consider?
You should consider the dialnorm setting, which is usually constant in a single "program" stream (i.e. can switch values if going to/from commercials, etc...). I don't know if there is a tool to view the AC3 frame info other than the one I made for my own use. It will be incorporated into Aften eventually.


BTW: Isn't Aften setting the lowpass too agressively? I will have to check again, but I think for 5.1/384kbit it was 14kHz (or maybe 16kHz). The source AC3 has it at 17-18kHz.
It is a tad aggressive, yes, but you can change it. The default values will likely change before the next release anyway. For now, you can use "-w 39" to get about a 17.8 kHz cutoff w/ 48kHz source audio.

[Boulder]

Something I've wondered: should one use any low- or high-pass filters or are they disabled by default because it's recommended not to use them in general?

[foxyshadis]

Lowpass mostly depends on your speakers and your hearing. If you can't hear above 16 or 18k anyway, there's no point in encoding anything above it. (100Hz-10kHz is the most important.) And usually there's quite a bit of information there, so raising the lowpass will leave lower frequencies spread across less bits, so more distorted if it's not high enough. If the source is already low-passed, as most are, it's not such a big deal unless you want to lower it further.

Highpass is only useful if you have a lot of low rumble that you need to get rid of, like phonograph recordings, so it doesn't rattle your neighbors' windows.

Um, it wasn't us who turned it up, no sir off'cer...

[jruggle]

Something I've wondered: should one use any low- or high-pass filters or are they disabled by default because it's recommended not to use them in general?
All of the input filters are recommended by the specification and/or Dolby. But since the effect on quality is not very large, and the speed cost is huge, they are not enabled by default.

[chros]

Can I use the new aften.exe with an avisynth script, how? (so no need for the intermediate wav file)

I tried, but no success ...
Thanks

[DarkAvenger]

I guess using the dll would be better.

[BigDid]

Or via Soundout 0.98 from Sh0dan, which has ac3 output and uses aften:
http://forum.doom9.org/showthread.php?t=120025

Did

[chros]

Thanks, I'll look into it ...

[LigH]

Where is kurtnoise?

http://kurtnoise.free.fr/ is not available (anymore | at the moment?).

[BigDid]

Where is kurtnoise?

http://kurtnoise.free.fr/ is not available (anymore | at the moment?).
Well,

His last post on doom9 was on 2/15 and on french forum unite-video a few hours ago. The Free page is also/still unavailable.

Did

[HeadBangeR77]

His repository page is up again, including Aften rev.382 from today - looks like he's been busy doing a lot of good work for audio community. ;)

[raquete]

including Aften rev.382 from todaythanks to show the news.
looks like he's been busy doing a lot of good work for audio community.really. :)

[wisodev]

I have released version 0.4 of WAV to AC3 Encoder.

Program website:
http://www.thefrontend.net/EncWAVtoAC3/index.html

Binary Package (Win32 and Win64):
EncWAVtoAC3-0.4-bin.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-bin.zip?download) | EncWAVtoAC3-0.4-bin.rar (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-bin.rar?download)

Installer Package (Win32 and Win64):
EncWAVtoAC3-0.4-installer.exe (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-installer.exe?download)

Source Package (VC++ 2005):
EncWAVtoAC3-0.4-src.zip (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-src.zip?download) | EncWAVtoAC3-0.4-src.rar (http://prdownloads.sourceforge.net/thefrontend/EncWAVtoAC3-0.4-src.rar?download)

Changelog:

Version 0.4:
- added to status bar 'Encoded # files in #'
- changed presets configuration file extension from *.cfg to *.presets
- added program configuration file with extension *.cfg
- added load/save configuration of last main dialog position
- added load/save configuration of all lists column sizes
- added load/save of currently selected preset
- added grid lines to file list and settings list
- added status bar
- added encoding time information to status bar
- added resizing to main dialog
- added drag & drop for files and directories
- added support for Windows 98 SE using Ansi builds


Thanks,
wisodev

Note: I'll update website later because Project Shell Service at sf.net is down.

[shae]

Just to be helpful, I've added an option to the commandline to remove the start-of-stream padding.
Thanks. I think Kurtnoise compiled it by now, but maybe, nevertheless, I should get an SVN client already. :)

In their encoded state, which is in the frequency domain, each frame is independent, but when decoded into the time domain, the blocks of audio samples are overlapped and added to get the final pcm output.
Is this some sort of "deblocking"? And does it mean that each frame in fact encodes 1536+256 samples? Is the mixing a simple (a+b)/2 for each of the 256 samples, or something more elaborate?

I read the SF thread but I'm not clear on why this 256 sample delay is needed. Sure, the very beginning would not be true to the source, but it would be practically unnoticeable. I think cases in which these 256 samples are important are rarer than those in which accurate length or positioning is important.

How about having "-pad 0" the default and allow the opposite override?

You should consider the dialnorm setting, which is usually constant in a single "program" stream (i.e. can switch values if going to/from commercials, etc...).
Since I'm replacing frames in-place, and reencoding a few untouched frames before the changed area then chopping them off, I suppose the overlapped samples would stitch ok, right?

Do you have an estimate on when your AC3 info tool will be released, standalone or as part of Aften? If it'll take a while, perhaps I'd write a simple one in the meantime.

For now, you can use "-w 39" to get about a 17.8 kHz cutoff w/ 48kHz source audio.
Not (22khz * w / 60)?

[BigDid]

His repository page is up again, including Aften rev.382 from today - looks like he's been busy doing a lot of good work for audio community. ;)
Yep,

And I believe this rev is MT friendly :)

Thanks Kurtnoise

Did

[jruggle]

Thanks. I think Kurtnoise compiled it by now, but maybe, nevertheless, I should get an SVN client already. :)


Is this some sort of "deblocking"? And does it mean that each frame in fact encodes 1536+256 samples? Is the mixing a simple (a+b)/2 for each of the 256 samples, or something more elaborate?

It's not deblocking, but part of the MDCT mathematics which is called time-domain alias cancellation. And yes, it sort of does encode 1536+256, or rather, it requires the previous 256 samples to 'accurately' encode the 1st of the 6 blocks. In Aften, we assume that the 256 samples prior to the start of the stream are silent. This ensures that the audio we actually want to encode is represented accurately. The downside is the delay.


I read the SF thread but I'm not clear on why this 256 sample delay is needed. Sure, the very beginning would not be true to the source, but it would be practically unnoticeable. I think cases in which these 256 samples are important are rarer than those in which accurate length or positioning is important.

How about having "-pad 0" the default and allow the opposite override?

"practically unnoticeable" yes, but as including the silent delay samples is standard practice for AC-3 encoders, I would prefer to keep that the default.


Since I'm replacing frames in-place, and reencoding a few untouched frames before the changed area then chopping them off, I suppose the overlapped samples would stitch ok, right?

They would stitch ok, yes. 1 previous frame is enough.


Do you have an estimate on when your AC3 info tool will be released, standalone or as part of Aften? If it'll take a while, perhaps I'd write a simple one in the meantime.

Not too far in the future. It's parsing perfectly right now. It just doesn't output anything. :) I'm trying to decide on a good format for the output.

Not (22khz * w / 60)?
No, sorry this is so confusing. I do want to eventually change this option to use Hz instead. See 'aften -longhelp' for details on how to set the bandwidth.

[shae]

Not too far in the future. It's parsing perfectly right now. It just doesn't output anything. :) I'm trying to decide on a good format for the output.For now, I found out azid.exe can show some info even if not all, and only for the beginning frames (I assume). But that was enough to give me the dialnorm value, which I realized I needed.

As for output format... just a semi-cryptic compact form for each frame, then let GUIs handle it. Optionally, allow selecting which fields to display, and what frame range. Maybe also with some stats for the whole stream.

No, sorry this is so confusing. I do want to eventually change this option to use Hz instead. See 'aften -longhelp' for details on how to set the bandwidth.Since it's w*3+73, it appears the range is 60. And there are 256 bins. Isn't each of fixed bandwidth? (I was wrong in using 22khz above instead of 24, though).

[jruggle]

Since it's w*3+73, it appears the range is 60. And there are 256 bins. Isn't each of fixed bandwidth? (I was wrong in using 22khz above instead of 24, though).

Yes, each bin is of fixed bandwidth, but the minimum bandwidth is 73/256 of 1/2 sample rate. If you're dealing exclusively with 48kHz audio, the formula can be simplified as:
cutoff = (w * 281.25) + 6843.75
or the inverse if you know the cutoff and need the bandwidth code:
w = (cutoff - 6843.75) / 281.25

[newhaven]

hi,
i have a WAV that i encoded using VI in plogue that is 1 hour and 21 minutes in length. after i add the file and enocde in aften 0.6 the encoded ac3 file is only 20 minutes in length. can anybody point me in the correct direction?

thanks --newhaven

[DarkAvenger]

wavinfo source file?

[newhaven]

dark avenger,

sorry, as you can tell i am a newbie. what are you referring to when you ask waveinfo file. the wave i encoded with VI and plogue was a 32 bit 6 channel wave, and this is what i tried encoding in aften. i'm assuming o missed a step somewhere. thanks--newhaven

[DarkAvenger]

Well, if your aften package contains the wavinfo tool, it would be nice if you applied it on your source file to get assured aften detects the wave file correctly.

[HeadBangeR77]

Hello,
Every Afteen package comes with wavfilter.exe, wavinfo.exe, wavrms.exe. I don't know the commandline, but the one mentioned above shall give you some information on your source wav file.

cheers,
HDBR77

Ooops, I was late a bit. :p

[newhaven]

hello again,

despite alo tof searching, i cannot find any info, on how to use the utilities included in aften. can someone please post an explanation/link/anything.

thanks--newhaven

[HeadBangeR77]

You can always copy the whole path to the file (wavinfo) into the windows command line, with a parameter /help or -help (just guessing, works in most cases). ;)

[tebasuna51]

@newhaven
If you have a 1 hour and 21 minutes (4860 seconds), 32 bit (4 bytes) 6 channel wav and samplerate 48 KHz the wav size must be:
4860 * 4 * 6 * 48000 = 5598720000 bytes = 5.21 GB

If your wav have 5.21 GB is a Aften problem, but if your wav file is only 1.21 GB you have only 19 minutes, Aften work OK and your problem is in precedent steps.

[newhaven]

tebasuna,

the wave is 5.25 GB (5,637,574,776 bytes), so is this an aften problem?

i followed ursatmls directions from this post:http://forum.doom9.org/showthread.php?s=&threadid=83844 to create the wave.

any more suggestions?------newhaven

[tebasuna51]

the wave is 5.25 GB (5,637,574,776 bytes), so is this an aften problem?

Seems you have a buggy Aften version, is a typical problem with wav files > 4 GB ( two field in wav header have a overflow and only show 5.25 - 4 = 1.25 -> 20 minutes).

For instance, the -ignorelength parameter in NeroAacEnc permit ignore this two fields and continue encoding until the real end-of-file is reached. Other versions of Aften make the same (not needed any special parameter).

[newhaven]

strange,

when i used plogue to create the 32 bit wave file, i also split each channel into 6 seperate files. i have taken the 6 channels and used surcodes DTS program. the clock in surcode shows 1:21:33.72.
yet when i add the single 6 channel wave file into belight 0.22 rc1 the description is the following:

WAV-mutichannel-9216kbps-48000khz-00:19:25

regards-newhaven

[newhaven]

tebasuna,

i downloaded aften from kurtnoises site. to tell you the honest truth, i have had the same issue with every version of aften i have tried (please don't take this as an insult, i know alot of hard work has gone into this program, who knows, maybe it is something on my pc's end). the encWAV to ac3-0.4 program give me the same result. is there a way to rewrite the WAV header so aften will encode it properly, or is this somehting that must be taken care of by aften?

thanks----newhaven

[tebasuna51]

i downloaded aften from kurtnoises site. to tell you the honest truth, i have had the same issue with every version of aften i have tried (please don't take this as an insult, i know alot of hard work has gone into this program, who knows, maybe it is something on my pc's end).
Don't worry, isn't your PC, seems the 0.06 version have a regression with this issue, at least rev304 and rev432 from kurtnoise site don't work properly.

the encWAV to ac3-0.4 program give me the same result.
Yes is in Aften.exe the problem not with the GUI.
is there a way to rewrite the WAV header so aften will encode it properly, or is this somehting that must be taken care of by aften?
The header can't support wav > 4 GB because the fields to support the length (file and data) have only 4 bytes and 2^32 is the limit.
Old versions of aften work fine. If you don't need drc support (-dynrng #) you can use v0.05 from Kurtnoise site.

[tebasuna51]

This is the wavinfo output with a wav > 4GB
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
File:
Name: z.wav
File Size: unknown
Format:
Type: Microsoft PCM
Channels: 6
Sample Rate: 48000 Hz
Avg bytes/sec: 576000
Block Align: 12 bytes
Bit Width: 16
Channel Mask: 0x03F
Data:
Start: 44
Data Size: 224522240
[ warning! unable to verify true data size ]
Samples: 18710186
Playing Time: 389.80 sec
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The header have the fields:
LeeWavBi 1.0 analyzing file with 4519489580 bytes:
G:\z.wav
----------------------------------------------------------------------
ChunkID .....: RIFF
ChunkSize ...: 224522276 Error: Must be FileLength - 8 = 4519489572
Format ......: WAVE
Subchunk1ID .: fmt
Subchunk1Size: 16
AudioFormat .: 1 Integer data.
NumChannels .: 6
SampleRate ..: 48000
ByteRate ....: 576000
BlockAlign ..: 12
BitsPerSample: 16
OffsetData ..: 45
DataLength ..: 224522240 Warning: we assume Datalength = 4519489536
Duration ...: 7846.336 sec., (2h. 10m. 46.336 s.)
----------------------------------------------------------------------
Like you can see the fields ChunkSize and DataLength (4 bytes each) can't support the real values > 2^32. If we assume:
DataLength = FileSize - OffsetData +1
we obtain the correct duration.

Only if there are subchunks after the Data chunk (possible but not probable) these subchunks are treated as data.

[wisodev]

I have added AFTEN SVN R433 Win32 and Win64 binary and source packages to my website (http://win32builds.sourceforge.net/aften/index.html). This release includes PGO & IPO optimized builds with MMX, SSE, SSE2 and SSE3 assembly optimizations for Win32 (x86) and Win64 (AMD64). Also MT builds are available with parallelization enabled.

Download binaries Win32:
aften-svn-r433-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win32-bin.zip?download) (2 614 835 bytes)
aften-svn-r433-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win32-bin.rar?download) (499 826 bytes)
Download binaries Win64:
aften-svn-r433-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win64-bin.zip?download) (870 848 bytes)
aften-svn-r433-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-win64-bin.rar?download) (312 954 bytes)
Download sources:
aften-svn-r433-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-src.zip?download) (157 390 bytes)
aften-svn-r433-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-svn-r433-src.rar?download) (83 638 bytes)

Thanks,
wisodev

[tebasuna51]

r433 don't work with wav files > 4 GB.

[jruggle]

Don't worry, isn't your PC, seems the 0.06 version have a regression with this issue, at least rev304 and rev432 from kurtnoise site don't work properly.


Yes is in Aften.exe the problem not with the GUI.

The header can't support wav > 4 GB because the fields to support the length (file and data) have only 4 bytes and 2^32 is the limit.
Old versions of aften work fine. If you don't need drc support (-dynrng #) you can use v0.05 from Kurtnoise site.

Plain and simple...the wav file is invalid. This is a limitation of the wav format. Some programs out there will go ahead and read the file anyway and just make assumptions about the data size, ignoring the header. I prefer not to do this, as it is technically wrong.

However, I will look into temporarily putting in a commandline option to override the data size specified in the wav header so that these large files can be used.

edit: I added a "-datasize" option to current SVN for user override of data size, in bytes. It is untested at this point, so I'm not sure if it works 100% correctly yet.

[tebasuna51]

Plain and simple...the wav file is invalid. This is a limitation of the wav format. Some programs out there will go ahead and read the file anyway and just make assumptions about the data size, ignoring the header. I prefer not to do this, as it is technically wrong.
The wav file isn't invalid, only two header fields are invalid, not necessaries if we assume the Data subchunk is the last.

This kind of 'invalid' wav's are generated by habitual decoders (azid, faad, foobar-convert, AviSynth-style, ...).

'Some programs' like NeroAacEnc assume this undesired, but real, situation with the parameter -ignorelength, used by default by GUI's like BeHappy, MEGUI, ...

If we use 32 bit precision a 63 minutes multichannel wav file become unsupported by Aften. We can't use 32 bit to encode all movie audio tracks.
We can't use at all (16 bit precision) Aften to encode movie tracks long than 125 minutes.

However, I will look into temporarily putting in a commandline option to override the data size specified in the wav header so that these large files can be used.

edit: I added a "-datasize" option to current SVN for user override of data size, in bytes. It is untested at this point, so I'm not sure if it works 100% correctly yet.
The end user can't know the datasize.
Is more simple than that:

1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.

[raquete]

@ wisodev
no new EncWavtoAC3 version? you have gratefull user here!:)

[wisodev]

@ wisodev
no new EncWavtoAC3 version? you have gratefull user here!:)

I was working on Aften command-line builds and with this come dll builds of libaften.dll. I have added MMX,SSE,SSE2,SSE3 and MT optimized builds. Now I want to integrate this dll builds with WAV to AC3 Encoder to enable switching between different optimized builds witch best suites your hardware. Actually the new version witch will have number 0.5 has already some new things checked in subversion:

Current SVN changelog:
- added more detailed progress status for MT encoding in work dialog
- added option to select number of work threads for MT (number of threads is limited only with your hardware)
- added multi-threading support (two or more files can be encoded in separate threads at the same time)
- changed calculation of total progress in work dialog to more precise
- added elapsed time for current file progress and total progress in encoding dialog
- added filter for .wav files only when adding directory
- added context menu to file list
- fixed bug when user clicked encode button and there where no file in list
then the second time you clicked the encoding process did not start

You can browse sources online: https://svn.sourceforge.net/svnroot/thefrontend/EncWAVtoAC3/

I will be working on dll integration today so version 0.5 will be released very soon (of course if I do not run into some troubles ;-) and I need to add some sort of selection between Aften multi-threading and my version of multi-threading.

[jruggle]

'Some programs' like NeroAacEnc assume this undesired, but real, situation with the parameter -ignorelength, used by default by GUI's like BeHappy, MEGUI, ...

Ok. So would it be better if I added a similar option to Aften to always read data until the end-of-file?

[tebasuna51]

Ok. So would it be better if I added a similar option to Aften to always read data until the end-of-file?
My preferred solution is:
1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.
But I can accept anything ;)

[jruggle]

1) When input is STDIN the datasize must be ignored and continue encoding until end-of-file, unless a special parameter -TrustInDataSize is present.

2) When FileSize > 4GB the DataSize must be corrected by FileSize - DataOffset, or continue encoding until end-of-file. In this case (>4 GB) we can't never trust in DataSize.

Well, I can probably partially accommodate this. What I don't want to do is make it the default behavior to break the standard. So rather than a "trust data size" parameter, I prefer an "ignore data size" parameter, which could also be interpreted as a "read data until EOF" parameter. Also, I don't want to treat streaming input or large input any differently.

What I really need to do is to bite the bullet and try to implement a cross-platform way of getting 64-bit file size. Currently, Aften has different behavior on different systems. If the system is 32-bit, it can only detect IF the file size is over 2 GB because ftell returns an error. If the system is 64-bit, ftell does not return an error...AFAIK...because it returns a long, which would be large enough to hold the file size. Anyway..there are weird Windows issues to solve as well.

I can go ahead and add the option to read data until EOF...but it may not give accurate progress percentage during encoding until I get the file size stuff worked out. I'm not sure what to name the parameter though. I'm thinking something along the lines of "-readtoeof" or "-datatoeof" or "-ignoredatasize" or "-ignoreinputsize". I'm also open to suggestions...but lowercase only and the-shorter-the-better.

[tebasuna51]

"-readtoeof" is ok for me.

Thanks Justin.

[newhaven]

jruggle,

thank you for your willingness to accomodate. as far as naming this, your the creator, abbreviate it and maybe put a note on a read me in the install.


newhaven

[jruggle]

"-readtoeof" is ok for me.

Thanks Justin.

Good. That's what I chose. :) rev 435 removes the "datasize" option and adds "readtoeof". Keeping consistancy with other Aften syntax, you have to do "-readtoeof 1".

edit: note that the progress percentage will stop at 100% after the header data size is reached, but if this option is turned on, encoding will continue...it will just stay at 100% until encoding is done.

[Kurtnoise]

@wisodev: could you compile the last svn revision please ? I would like to compare something with my build...

Thank you.

[tebasuna51]

@wisodev: and can you explain, please, the differences between all the aften.exe options?