Is XDCAM import broken? No Audio!

Did you receive joema’s link in an email notification? That is what normally happens when sharing links are posted on the forum. Only subscribers will see the link only in email notifications.

Please upload to this WeTransfer link an example of an XDCAM file that won't play on your Mac Studio running MacOS 15.3.1. I have the same machine and am familiar with low-level codec details:

[Edited by Moderator]

I downloaded your clip and examined it. It plays without audio in current Quicktime and MacOS/FCP versions back to Ventura and FCP 10.6.5, and maybe earlier, on both Intel and Apple Silicon. When did this XDCAM material last work on MacOS and FCP?

The underlying problem involves an architectural issue called "endianness," which you can Google. It refers to the byte ordering of datatypes as they are written to memory. Decades ago, the Motorola 68000, IBM System 360, and successors were "big-endian" whereas the Intel x86, Digital Equipment VAX, and Data General Eclipse were "little-endian" as is Apple Silicon today.

Early video cameras used big-endian CPUs so that affected the natural byte order of audio data in memory and when written to disk. Over decades, CPUs slowly coalesced on little-endian designs, so the byte order of stored data changed. There are typically metadata flags that indicate this when written to files, and software is supposed to read that and, if required, swap the byte order to match the CPU.

MediaInfo output of the XDCAM file shows metadata "Format settings: Big / Signed" and "Codec ID: twos". This means the PCM audio is big-endian. By contrast, little-endian byte ordering is much more common today. \

There seems to be code in the FCP CoreAudio SDK framework that checks for this, presumably in preparation for byte swapping the data for the little-endian x86 and Apple Silicon CPUs. But it apparently handles the byte swapping incorrectly (or maybe doesn't even do it). I don't know how long it's been that way; apparently back to 10.6.5 or before.

The third-party utility EditReady can rewrap those XDCAM files so that FCP interprets the audio correctly.

I'll examine this further tomorrow and probably file a bug using the MacOS Feedback Assistant App.

I downloaded your clip and examined it. It plays without audio in current Quicktime and MacOS/FCP versions back to Ventura and FCP 10.6.5, and maybe earlier, on both Intel and Apple Silicon. When did this XDCAM material last work on MacOS and FCP?

The underlying problem involves an architectural issue called "endianness," which you can Google. It refers to the byte ordering of datatypes as they are written to memory. Decades ago, the Motorola 68000, IBM System 360, and successors were "big-endian" whereas the Intel x86, Digital Equipment VAX, and Data General Eclipse were "little-endian" as is Apple Silicon today.

Early video cameras used big-endian CPUs so that affected the natural byte order of audio data in memory and when written to disk. Over decades, CPUs slowly coalesced on little-endian designs, so the byte order of stored data changed. There are typically metadata flags that indicate this when written to files, and software is supposed to read that and, if required, swap the byte order to match the CPU.

MediaInfo output of the XDCAM file shows metadata "Format settings: Big / Signed" and "Codec ID: twos". This means the PCM audio is big-endian. By contrast, little-endian byte ordering is much more common today. \

There seems to be code in the FCP CoreAudio SDK private framework that checks for this, presumably in preparation for byte swapping the data for the little-endian x86 and Apple Silicon CPUs. But it apparently handles the byte swapping incorrectly (or maybe doesn't even do it). I don't know how long it's been that way; apparently back to 10.6.5 or before.

The fact that Quicktime Player itself doesn't play audio implies a lower-level framework in common between FCP and MacOS. The problem might be in the MacOS CoreAudio or AudioToolbox frameworks.

The third-party utility EditReady can rewrap those XDCAM files so that FCP interprets the audio correctly.

I'll examine this further tomorrow and probably file a bug using the MacOS Feedback Assistant App.

Javier, the new XDCAM clip recorded with internal mic doesn't play audio on FCP 11.1 through 10.6.5 on my machines. What year and model of Mac do you have? Also, please also give me the camera make and model.

Years ago there was an XDCAM plugin that was required to import that material to FCPX. I thought maybe with the switch from the 32-bit Quicktime framework to the 64-bit AVFoundation framework around 2018, that was no longer needed.

After rewrapping your XDCAM .MP4 file with EditReady, that changes the audio metadata seen by MediaInfo from "Format settings: Big/Signed" to "Little/Signed" and "Codec ID: twos" to "Codec ID: lpcm". Those changes are consistent with an "endianness" issue, as described above. I'll investigate further.

Would it be possible to share a clip with the problem through Dropbox or WeTransfer or similar?

Does this happen with clips that previously worked in FCP?

The XDCAM material I have on my system is not showing any problem. Either was already in an existing library or imported into a new library.

Can you please send me a clip where the internal mic was used. I want to examine the metadata and audio encoding for those vs the first clip you sent.