@DSPguru: I can definitely confirm that there is a problem around the 2 GB (for 16 bit WAV's) or 4 GB (32 bit WAV's) limit also here (XP-only systen, NTFS only, Intel Xeon 2.4 MHz, 1 GB RAM).
If I remember correctly (from memory), this only happens on certain machines, because I think there were 1 or 2 reorts of "things working now" (although no logfile as proof posted).
Eample 1: 16_00.wav (1.91 GB, == 2,054,369,324 bytes) works fine.
Code:
BeSweet v1.5b26 by DSPguru.
--------------------------
Logging start : 05/05/04 , 22:53:07.
C:\BeSweet\BeSweet.exe -core( -input i:\16_00.wav -output m:\16_00-New- -6ch -logfile C:\BeSweet\BeSweet.log )
[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : i:\16_00.wav
[00:00:00:000] | Output: FL, FR, SL, SR, C, LFE
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[00:00:00:000] +---------------------
[01:04:39:114] Conversion Completed !
[00:02:59:000] <-- Transcoding Duration
Logging ends : 05/05/04 , 22:56:07.
Eample 2: 16_01.wav (2.02 GB, == 2,179,430,444 bytes) crashes.
Code:
BeSweet v1.5b26 by DSPguru.
--------------------------
Logging start : 05/05/04 , 22:57:14.
C:\BeSweet\BeSweet.exe -core( -input m:\16_01.wav -output i:\16_01-New- -6ch -logfile C:\BeSweet\BeSweet.log )
[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : m:\16_01.wav
[00:00:00:000] | Output: FL, FR, SL, SR, C, LFE
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[00:00:00:000] +---------------------
<i.e. end of logfile>
The DOS-Windows 1st hangs with this message:
Code:
BeSweet v1.5b26 by DSPguru.
--------------------------
[01:08:34:892] transcoding ...
Thereafter, BeSweet crashed "BeSweet.exe has encountered a problem and needs to close":
Code:
AppName: besweet.exe AppVer: 0.0.0.0 ModName: besweet.exe
ModVer: 0.0.0.0 Offset: 00010c36
Same "picture" of 32 bit WAV's (no logfile posted).
This error is reliably reproducible here.
I think "it" happens at the very end of BeSweet's pass, as the 6 mono-WAV's are written to their correct length [01:08:34:892].
With the growing number of Bidules, I really hope for a fix (although things can be done manually with CoolEdit(*) or SoftEncode).
Kind regards,
Andreas
(*) Off-topic add-on (because I think someone asked):
If opening multichannel wav files with CoolEdit (i.e. 16_01.wav), it will open things as 16_01.wav, 16_01(1).wav, 16_018(2).wav, ... , 16_01(5).wav.
Assuming that ITU 5.1 channel mapping for Bidule's Audio File Recorder was used, the mapping will be as follows:
16_01.wav -> L
16_01(1).wav -> R
...
16_01(5).wav -> SR