View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000466 | eac3to | bug | public | 2017-01-16 19:48 | 2017-01-17 23:08 |
Reporter | jpsdr | Assigned To | madshi | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | PC | OS | Windows 7 | ||
Summary | 0000466: Issue with more than 4Gb wav files | ||||
Description | I 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 Reproduce | Decode a thd 5.1 files from which each channel will result in a more than 4Gb file length. | ||||
Tags | No tags attached. | ||||
eac3to Version | 3.30 | ||||
|
Fogot : If necessary, i can provide you the file on an ftp server. |
|
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. |
|
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). |
|
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. |
|
.... 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 ? |
|
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. |
|
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. |
|
So, problem solved? |
|
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". |
|
Since it's not a bug, I'm closing. |
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 |