.aif files import as .rf64

[sunrat]

After importing a bunch of .aif files recorded in Logic, they become .rf64 files in /interchange/audiofiles/ and throw up this error in the log which says it is not an error:

Code:

2020-02-19T16:42:44 [ERROR]: Cannot mark RF64 audio file for automatic downgrade to WAV: No Error.

Is it anything to be concerned about?

I tried converting the .aif files to .wav with Sox but they still become .rf64 in the session after import and throw the same error/non-error. I'm also seeing ~3 xruns per file during import but none while playing so that may be unrelated and also a non-issue.

[sunrat]

Nobody knows why this happens?
I just imported 24 1.1GB .wav files which were recorded in Reaper and they also became .rf64 in the audiofiles folder. Still curious why.

[madmaxmiller]

Nobody knows why this happens?
I just imported 24 1.1GB .wav files which were recorded in Reaper and they also became .rf64 in the audiofiles folder. Still curious why.

I'm not using Reaper, so apart from one MIDI track I created there for checking it out it's "virgin"...
So I recorded a few seconds of audio in Reaper/Linux v5.980, then imported the created wav file into Mixbus 32C v 6.0.251 - and it's still wav... Have you done some settings in Reaper, for example to create 64-bit wavs?

MMM

[sunrat]

... Have you done some settings in Reaper, for example to create 64-bit wavs?

The files in the Reaper (Windows) session are .wav files. They only gain the .rf64 suffix after importing.
Note that an .rf64 file is not a 64 bit file. It is a standard .wav file, in this case 24 bit, with a 64 bit header. They still play the same, albeit with the non-error noted in my first post. I'm just curious why it happens and why it doesn't happen with all imported files.

[madmaxmiller]

... Have you done some settings in Reaper, for example to create 64-bit wavs?

The files in the Reaper (Windows) session are .wav files. They only gain the .rf64 suffix after importing.
Note that an .rf64 file is not a 64 bit file. It is a standard .wav file, in this case 24 bit, with a 64 bit header. They still play the same, albeit with the non-error noted in my first post. I'm just curious why it happens and why it doesn't happen with all imported files.

Yeah I read a bit about it in the meantime...
Is that Reaper session multi-channel?
Also, Reaper might create a 64 bit header when you have disabled file splitting - a 64 bit header allows for files > 4GB... (look in Options -> Preferences -> Audio -> Recording -> "start new files every...")
Reaper might save that as wav for its internal use (maybe changes it at the 4GB "barrier") but Mixbus may name it after the header it sees...
I'm sure Robin knows

MMM

[sunrat]

Is that Reaper session multi-channel?

No, this one was 24 mono .wav files.

Also, Reaper might create a 64 bit header when you have disabled file splitting - a 64 bit header allows for files > 4GB... (look in Options -> Preferences -> Audio -> Recording -> "start new files every...")

These appear to have been split at 1GiB. I didn't change default option there. I recall it being a rush job to get it set up for the show.

Reaper might save that as wav for its internal use (maybe changes it at the 4GB "barrier") but Mixbus may name it after the header it sees...

I tried briefly and unsuccessfully to work out how to see if the header is actually 64 bit. ffmpeg and MediaInfo don't show it. I will investigate that further...

OK I just checked, Session Properties > Media > File type: is set to RF64 (WAV compatible). I'm pretty sure I never changed that.
And to confuse matters more, I had imported the "Angels In Amplifiers" test session to both MB32C v5 and v6. In v5 it imported the 44.1kHz files as .rf64 . In v6 I converted the files to 48kHz before importing and they imported as .wav. Another session I imported to v6 from a Logic session recording of a concert by The Necks imported (from .aiff files) as .rf64 .

I'm sure Robin knows

I hope so

[Dingo]

Dated, but this article may be of interest
https://discourse.ardour.org/t/whats-ur-...-caf/90472

[sunrat]

Dated, but this article may be of interest
https://discourse.ardour.org/t/whats-ur-...-caf/90472

What Paul said in that article is of interest but is pretty much what I already knew - that a 64 bit header is required for timestamp data in files over about 4GB. Can I infer that timestamp data is still present for shorter files even with a 32 bit header, ie. standard WAV?
The longest files I have ever imported are under 2 hours @ 24 bit, so don't even approach the 4GB limit.
Still no closer to understanding why some files import as .rf64 and others as .wav.

[madmaxmiller]

Dated, but this article may be of interest
https://discourse.ardour.org/t/whats-ur-...-caf/90472

What Paul said in that article is of interest but is pretty much what I already knew - that a 64 bit header is required for timestamp data in files over about 4GB. Can I infer that timestamp data is still present for shorter files even with a 32 bit header, ie. standard WAV?
The longest files I have ever imported are under 2 hours @ 24 bit, so don't even approach the 4GB limit.
Still no closer to understanding why some files import as .rf64 and others as .wav.

Have you imported the very same files into Ardour? Just for fun? Can I download one of these to see how it behaves here?
MMM

[sunrat]

I just tried creating a few sessions importing several recordings. It seems files are always stored according to the setting in Session Properties > Media > File which is logically obvious. I also looked through a bunch of old sessions and the older ones are all saved as .wav but most of the newer ones are .rf64 . This is regardless whether MB32C v5 or v6. I say most as there are a couple which are saved as .wav which throws the theory that the default import save format was changed at a particular time. Still confused but a bit clearer now.
So the burning question is - how to I change it so default is .wav?

@MMM I tried importing to Ardour, it defaults to .wav. Not worth uploading one for you as the source file doesn't seem to matter.