Error: could not move audio asset into the DCP

[Googloiss]

Hi, I'm new here and I've just failed trying to make my first DCP with o-matic for my new short film. I come from openDCP, where I've never had any problems in the past, but o-matic is more modern and complete so I wanted to use it instead.

I thought I did everything right but at the end of the process I had this error: "could not move audio asset into the DCP (3) with pcm_e6ec7b22-7470-475d-85e6-cfe3d1227bd3.mxf". Why? I have not found any mention or solution to this error on the web.

I started with a prores 4444 source file, nothing strange I think. Audio track is stereo 2.0 but under the advice of the program I set 5.1 for the DCP.

Thanks to those who want to help me.

[carl]

Can you attach the "log" file from inside the DCP-o-matic project, or email it to carl@dcpomatic.com ?

[Googloiss]

Hi Carl, thanks for responding. I was able to make the DCP and not get that error simply using a shorter name for the o-matic's project... I don't know if that's really what caused the error, at first I tried to put the project folder in an empty folder but the error came again, when I shortened the project name instead the DCP was finally created without errors (although there are warnings in the log file, but from what I understand it's normal).

But now I have another problem. I'm using media player classic home video player (with color management on, I have a calibrated wide gamut monitor) to check the mxf video file generated, comparing it to the prores 4444 source file. And the result it's a slightly darker image, not only in the shadows but also in highlights. Is it a normal behaviour for a DCP making? Colour range is right, limited, it matches the source file (as I can see in the properties of the source file within o-matic). Also, the preview in o-matic seems right, it's not darker.

I've tried some tests playing with input gamma in the colour conversion window, I've found that gamma 2.2 is associated with rec.709, but my source file should be rec.709 gamma 2.4 (I came from a Premiere export, where you can't choose an output gamma like in davinci, but from my tests it's a 2.4, because it matches what previously came from my davinci project, that is 2.4 for sure), so I set gamma 2.4 (that is the BT.1886 preset), and the result was even darker. So I did the contrary, setting gamma 2.0, and this time was too bright, and not only that, it was also less contrasty because highlights have not reached the same level of the source file, while shadows have become lifted... What's happening? How can I get an exact conversion of what I see in the source file? Assuming this is the goal, because again, I'm not sure if this darker behaviour is normal or not for a DCP, I'm not a super expert of DCPs... Or maybe prores 4444 is too much to handle? Should I try prores 422 HQ?

[Carsten]

You can not judge DCP colors using a non-standard playout solution. Some solutions may get you closer to the source than the other, but in general, if you are concerned, you must take it to a cinema or screening room.

[Googloiss]

I know I should test it in a cinema environment, but at the moment I can't and I have to find another way of testing. MPC-HC player is a reliable video player from what I know (I use it as it is from install, I only enabled color management), it's not like vlc or quicktime that have many problems regarding gamma shifts or color management.

By the way, I don't understand why this change happens, what dcp-o-matic's setting caused it?
It's not about colors, they are right (MPC-HC has to do an automatic internal conversion from xyz to rgb space, because I don't see the typical brownish/pinkish of xyz image that's seen from an rgb device), it's about brightness. Other than MPC-HC, what color managed software can I use to check mxf video file? I tried premiere and after effects but after successfully importing the mfx file all I can see is a black/transparent screen, no picture is shown, I don't know why.

[Carsten]

There are various DCP players around, all offer different color transform methods/options. Now, you may try one of these and find a setting that matches your source. What tells you that this setting matches the color rendition in a cinema? It may lead you towards a false impression.

The spec'd color renderer for DCI is an X'Y'Z' transform to P3. Do you have a P3 display device with a 2.6 gamma? If not, you can not trust the playback. All you have is probably a rec.709/BT.1886 device.

If you think you can use a rec.709 display to properly display your DCP - why do mastering studios invest many thousands of dollars into grading projectors or displays?

- Carsten

[Googloiss]

So it's normal to have any kind of mismatch between the prores master and final dcp viewed on a windows machine through a player like MPC-HC? I have a calibrated wide gamut monitor that covers 97% of P3 gamut. But that's not my point, I made my color grading inside resolve and a decklink card, so I know that viewing the result passing through an OS like windows is not reliable, but what I don't understand is why, taking an equal, albeit wrong, viewing base with MPC-HC, the prores master and the converted final dcp don't match. Even if the prores master on MPC-HC doesn't show the real result, the final dcp should show the same wrong result, it's a conversion, but why it doesn't happen?

I've spent the whole day testing dozens of setting combination either with o-matic than with opendcp/j2c plugin, and finally I've found a way (one and only) that makes the mxf video look identical to the prores master inside MPC-HC. I had to use the DCI converter for after effects by fnord, with a gamma 2.2 response curve, D65 and normalize option unchecked. If I try that same settings inside o-matic, it corresponds to rec.709 preset, but it gives me that darker result, I think the normalize option makes the difference here, because if I check it, the image become darker, so it's like if o-matic have a built in normalize feature that cause this darker behaviour and can't be unchecked. Am I seeing this right or have I misinterpreted?

That said, I wil try to see these results in a real cinema, but it will be complicated for me to find one available to do such favor... Meanwhile I'd like to investigate those results with you, as they can also come in handy for someone else out there.

[Googloiss]

Up!

[Carsten]

I never tried MPC-HC for DCP playback. The DCP/J2K decoding option was a late addition and is pretty much underdocumented, as are many other features of their playback/color processing framework (look at the various video decoding option in windows alone - same for VLC). The trouble is that rec.709/sRGB supports a very different viewing environment than the cinema. Some players do a plain-vanilla re-transform from X'Y'Z' to sRGB or rec.709, some apply tweaks to make the result more compliant on a typical computer display. The trouble simply is, you can try various players and settings - but none of this will give you confidence in what it actually will look like in the cinema.


You may check a recent version of VLC as well. When you do a screen grab (VLC internal video snapshot feature, not system screenshot), I found the resulting file very close to what the DCP looks like in the cinema, on a plain sRGB display.

If you don't have a chance to watch that DCP in a cinema - for what purpose did you create a DCP?

[Googloiss]

Hi! I'm picking up the project after a little break.

VLC seems to be unable to take snapshot from mxf files, if I click on the command, nothing happens.
Now I'm finally testing with Resolve, more than one person has suggested to me this is the best low budget comparison method to try.

First question: Resolve has the ability to import and read an entire DCP folder? I don't know how to do that.
So for now I imported only the mxf video file from the DCP folder.

Second question: the input color space for the mxf video file is DCI X'Y'Z', correct? I selected this one, which was also what resolve had already selected by default for this file.

Now, what I have is a pinkish image, but that should be normal due to the DCI X'Y'Z' color space, right?
What I'm looking at is only luminance (Y) on the waveform, because apparently my problem is on that side of the resulting conversion.

And now I should only choose the conversion settings that match the most with the waveform of the prores master inside Resolve. Is this a reliable way of judging the conversion? Or at least more reliable than MPC-HC? Because I'm already seeing a different result compared to MPC-HC.

When I've figured out the best comparison method on a windows machine and chose the best conversion, then I will do a quick test in a local cinema (they do me this as a favor). Thank you!