Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: The 2GB Wav-limit!? (Read 63342 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

The 2GB Wav-limit!?

Reply #50 –
Quote
>Its a backwards compatible

Perhaps not for the poorly written programs (ones that expect a 'fmt ' at a certain location, instead of walking the chunks...). Other than that, I like it, and will be implementing it.
[a href="index.php?act=findpost&pid=334627"][{POST_SNAPBACK}][/a]


That's great. Thanks.

I hope other developers embrace it too.

The 2GB Wav-limit!?

Reply #51 –
I received information the other day about an alternative solution promoted by Sony that is mentioned in that paper and described here:

http://media.vcs.de/Downloads/Sony_Wave64.pdf

Hopefully one standard will emerge. In any event, sounds like a nice enhancement for WavPack soon...

The 2GB Wav-limit!?

Reply #52 –
I have not tested this extensively, nor looked at the documentation, but I discovered a while back that n-Track Studio just keeps going when it reached 2G by starting another file. As far as I could determine, it never dropped a sample, the second file just continued perfectly. This approach could allow unlimited length recordings in a not-so-expensive program. I have the 24 bit version of n-Track Studio.

The 2GB Wav-limit!?

Reply #53 –
Ok to retract my previous statement 'Its a backwards compatible' - in it's current form it is not because if you look at the docs, RIFF (first four bytes in the file changes to 'RF64') I have written to them to suggest that it should stay 'RIFF' then old programs will play the files upto 4GB and newer programs should read the 'ds64' chunk and will know the true length.

Wave64 seems to be used a fair amount, not sure I like the change of simple chunks (ie 'fmt ') to full blown UUIDs, seems pointless (are there going to be 100 billion x 100 billion chunk identifiers? no.

The 2GB Wav-limit!?

Reply #54 –
Quote
Ok to retract my previous statement 'Its a backwards compatible' - in it's current form it is not because if you look at the docs, RIFF (first four bytes in the file changes to 'RF64') I have written to them to suggest that it should stay 'RIFF' then old programs will play the files upto 4GB and newer programs should read the 'ds64' chunk and will know the true length.
[a href="index.php?act=findpost&pid=334678"][{POST_SNAPBACK}][/a]

I don't think so, just from a quick read. I think the idea is that the file is identical to a standard wav as long as it's less than 4 gig, except that there's room in a dummy chunk (after "fmt") to expand the header when the file size exceeds 4 gig. At that point the RIFF chunk at the beginning is replaced with the RF64 (and the extra space is used so there's no shuffling of the whole file).

I don't think it would be very good if wav files bigger than 4 gig simply appeared to unaware applications as shorter than they really were without any warning for the user. Instead, they should simply be unreadable when they are bigger than 4 gig.

The 2GB Wav-limit!?

Reply #55 –
Quote
Ok to retract my previous statement 'Its a backwards compatible' - in it's current form it is not because if you look at the docs, RIFF (first four bytes in the file changes to 'RF64') I have written to them to suggest that it should stay 'RIFF' then old programs will play the files upto 4GB and newer programs should read the 'ds64' chunk and will know the true length.

It seems to me that old software will be broken on >4GB files no matter what you do.  I'd rather have the failure mode be an immediate error rather than silent truncation.  Of course, if you're going to change the file type, why bother with the ds64 chunk?  Why not just expand the necessary fields to 64-bit like Wave64?

Edit: David said it first.

Quote
Wave64 seems to be used a fair amount, not sure I like the change of simple chunks (ie 'fmt ') to full blown UUIDs, seems pointless (are there going to be 100 billion x 100 billion chunk identifiers? no.

I'm with you here.  I saw that for the first time today and it struck me as incredibly stupid.

The 2GB Wav-limit!?

Reply #56 –
Quote
It seems to me that old software will be broken on >4GB files no matter what you do.  I'd rather have the failure mode be an immediate error rather than silent truncation.
Of course, if you're going to change the file type, why bother with the ds64 chunk?  Why not just expand the necessary fields to 64-bit like Wave64?

I brought another brain cell in on this, and its telling me that since they stated a desire for backwards compatibility, the RIFF sig should be used, until the size exceeds 4 gig (or extra channels etc required), then it can be changed to RF64 and the junkchunk is utilised for extending the file. (Its written in at the start because its much harder to add later if/when itturns out to be needed)
Id like the fmt chunk to stay first. Its just a small but nice consideration if basic formats can be coded simply when possible. Would help students and amature enthuasts get a handle, keeping basics accessible, avoiding unnecessary layers of metafluff.
No more braincells available atm for finding out the proposed new chunk order.
no conscience > no custom