View Issue Details

IDProjectCategoryView StatusLast Update
0000466eac3tobugpublic2017-01-17 23:08
Reporterjpsdr Assigned Tomadshi  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformPCOSWindows 7 
Summary0000466: Issue with more than 4Gb wav files
DescriptionI have a very big (12Gb) 192kHz 24bits 5.1 TrueHD audio file.
I've tried to decode it with "-wavs" option.
eac3to warned me that more than 4Gb files may not be handled/opened properly by some programs.
Fine... Except that files were truncated exactly at 4.00Gb size. So, it seems that, at least in that specific case, eac3to can't create more than 4Gb files.
Steps To ReproduceDecode a thd 5.1 files from which each channel will result in a more than 4Gb file length.
TagsNo tags attached.
eac3to Version3.30

Activities

jpsdr

2017-01-16 19:49

reporter   ~0001571

Fogot : If necessary, i can provide you the file on an ftp server.

madshi

2017-01-16 21:34

administrator   ~0001572

Strange. Your file system does support files bigger than 4GB, does it? I think Fat32 does not. But I suppose everybody uses NTFS these days.

jpsdr

2017-01-17 09:37

reporter   ~0001576

More information : System is NTFS, but i was wrong on something. I thought what "screw up" the file was because it was truncated to 4Gb, but not. The final real size of the file is 4.005 Gb, and this was correct after check.
The issue seems to be that the wave header of the wave files when using ".wavs" is the "old" header (which doesn't work for >4Gb files), not the w64 header, so every program i trie to open with said that the length is 11s... (the 0.005Gb left on 192kHz 24bits data).

madshi

2017-01-17 10:05

administrator   ~0001577

Well, there's no ".wavs64" option. But I think you should be able to use eac3to to convert each of the final 4.005GB wav files into wav64.

jpsdr

2017-01-17 11:33

reporter   ~0001578

.... Will it work ? I mean the "size" tag in the RIFF header is wrong, will eac3to not produce a wav64 of only the 0.005Gb remaining if it uses the "size" information from the RIFF header, which seems somehow logical to do ?
Is it not possible to just add a ".wavs64" option ? As you have already the code to produce wav64 ?

madshi

2017-01-17 12:20

administrator   ~0001579

Why not simply try? But yes, I believe it should work.

Adding .wavs64 extension support would be possible, but atm my development resources are concentrated on madVR, so it won't happen any time soon, especially considering that I believe you can use the workaround I suggested.

jpsdr

2017-01-17 20:04

reporter   ~0001580

Back home, been able to make some tests (it took a little long).
Finaly W64 wasn't the solution, because i thought i could read them but in fact no. So, converting to RAW was the solution, and it works.

madshi

2017-01-17 20:20

administrator   ~0001581

So, problem solved?

jpsdr

2017-01-17 22:41

reporter   ~0001582

Warkaround is working, but it's still a workaround, the root of the problem is not solved, but i'm not stucked.
You may consider in the future to add the ".RAWS" option. This way, no possible header issue, the files created will always be "good".

madshi

2017-01-17 23:08

administrator   ~0001583

Since it's not a bug, I'm closing.

Issue History

Date Modified Username Field Change
2017-01-16 19:48 jpsdr New Issue
2017-01-16 19:49 jpsdr Note Added: 0001571
2017-01-16 21:34 madshi Note Added: 0001572
2017-01-17 09:37 jpsdr Note Added: 0001576
2017-01-17 10:05 madshi Note Added: 0001577
2017-01-17 11:33 jpsdr Note Added: 0001578
2017-01-17 12:20 madshi Note Added: 0001579
2017-01-17 20:04 jpsdr Note Added: 0001580
2017-01-17 20:20 madshi Note Added: 0001581
2017-01-17 22:41 jpsdr Note Added: 0001582
2017-01-17 23:08 madshi Status new => closed
2017-01-17 23:08 madshi Assigned To => madshi
2017-01-17 23:08 madshi Resolution open => no change required
2017-01-17 23:08 madshi Note Added: 0001583