Talk:RF64

Professional sound production Mid‑importance

	This article is within the scope of WikiProject Professional sound production, a collaborative effort to improve the coverage of sound recording and reproduction on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Professional sound productionWikipedia:WikiProject Professional sound productionTemplate:WikiProject Professional sound productionProfessional sound production articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Upper limit[edit]

How far in excess of 4GB? Unlimited or is there a certain (large) file size limit? The upper limit should be stated in this article. Binksternet (talk) 14:14, 14 May 2008 (UTC)[reply]

The limit of 4GB is due to 32-bit addressing methods. RF64 uses 64-bit addressing, so i guess the maximum size will be (2^64) bytes, which will be 16 ExaBytes (+- 16000000 terabytes). 192.87.219.33 (talk) 12:02, 7 October 2008 (UTC)[reply]

And the allowed, typical, actual file extensions are?[edit]

Why is there no mention of which file extensions are applicable?173.189.72.93 (talk) 20:21, 14 November 2014 (UTC)[reply]

The specification says that the file extension should be '.wav', even though '.rf64' or '.bw64' should also be accepted by an application opening a file. In the end, it's often best to ignore extensions anyways and try to determine the format from the file contents. 94.134.174.116 (talk) 07:18, 14 June 2021 (UTC)[reply]

BW64?[edit]

On February 29th 2020, the RF64 page was edited by @Artoria2e5: Among the many changes I otherwise agree with, I noticed that the the description of the first four bytes of the file was modified from 'RF64' to 'BW64'.

I'm not familiar with the 'BW64' format, but I know that many (all?) RF64 files I have ever worked with, begin with the bytes 'RF64'. Is it possible that 'BW64' is an extension of 'RF64'? Should it have its own separate page, or possibly be moved to the Broadcast Wave Format article?

If 'BW64' is a valid value for RF64 also, then we should probably just update the article to indicate that either 'RF64' or 'BW64' are valid replacements for 'RIFF'.

I think there is a bit of confusion going on in this article. As far as I see it, there are two different specifications, one by the European Broadcasting Union (EBU), which defines the RF64 format, and one by the International Telecommunication Union (ITU), which defines the BW64 format. They are almost identical, but use a different header signature, define a slightly different (but largely overlapping) set of chunks allowed in the files, and differ in the contents of their 'ds64' (64-bit data size) chunk, where RF64 defines the third 64-bit word after the length field as being the number of samples stored in the 'DATA' chunk, while BW64 defines the third 64-bit word after the length field as being zero when written by a compliant client, but ignored when being read. Therefore, the same code can be used to read RF64 and BW64 files, as long as it accepts both file header "signatures" and does not validate this length field (of which the value can also be deduced from the length field of the 'DATA' chunk and the "byte align" field in the 'fmt' chunk). However, a compliant RF64 parser might choose to validate the value of the "sample count" field in the 'ds64' chunk against the size of the 'DATA' chunk, so a BW64 file cannot simply be "downgraded" to the older RF64 format just by replacing the first two bytes of the file. It's a bit disturbing that the formats are (apart from optional chunks, which can be ignored) 99 % identical, but differ in such a small detail though. I think we should describe both formats in this article. It's good that both specifications are already referenced though. 94.134.174.116 (talk) 07:18, 14 June 2021 (UTC)[reply]