This is topic DCP-o-Matic and Barco Alchemy in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.
To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=003247
Posted by Leo Enticknap (Member # 534) on 03-08-2018, 11:26 AM:
It was mentioned recently in another thread (just tried to find it but can't - sorry), that there is a known bug in the post-2.10.5 beta versions of DCP-o-Matic, whereby a DCP made with it and ingested into a Barco Alchemy causes the Alchemy to crash (you press play, nothing happens, and then the Alchemy has to be rebooted). I also seem to remember Carl or Carsten saying that a fix was imminent.
Is this fixed in the current beta, 2.11.70? I ask, because someone has asked me to make a 4K DCP from DPX frames, simulating a frame rate of 17fps, and with subtitled translations of silent movie intertitles (which is a pain in the bum to do using Premiere Pro with Cute DCP, which is the other DCP-making package I have), which will specifically be for playback on an Alchemy. I note in the list of improvements and fixes that there are several relevant ones to 4K and DPX rendering, but if there is any risk of this glitch happening, then obviously I need either to use 10.0.5, or to go the Premiere route.
Posted by Carsten Kurz (Member # 5396) on 03-08-2018, 11:59 AM:
Hi Leo, that specific openjpeg glitch caused problems on both Barco and Dolby servers.
It came up with 2.11.23 and left us with 2.11.34, so, 2.11.70 is fine as far as that goes. The mentioned 4k issue was just a formal one and is solved as well, DPX seems to work fine as well, there were some issues with misinterpretation of log/film gamma. I think there has been no full testing on all DPX variants since then, but if the DPX export is not too exotic, it should come out ok. As DPX are single image files, it's easy to do a quick still test with just one image showing bright and dark content.
Carl was working like mad since new years eve to get many bugs fixed and features added, as you can see he is on build .70 in the 2.11. test branch. He hopes to transition to 2.12 stable soon.
Please, anyone using the software, go to https://dcpomatic.com/donate and donate some money. The higher the number of donating people, the smaller the amount will be sufficient to keep it going. Carl has a family now to support. The new DCP export functions and self-contained fully functional DCP test player (audio, 4k, subtitles, OV/VF capable) are great new features, worth paying for again.
- Carsten
Posted by Leo Enticknap (Member # 534) on 03-08-2018, 05:53 PM:
Many thanks for confirmation; donation made.
As this is for a one-off show in a specific venue, ordinarily I could just do a re-render using an earlier version, or the Premiere/Cute route; but on this occasion, she's not going to be able to get me the source files until very close to showtime, so I'm probably only going to get one shot at it.
Posted by Monte L Fullmer (Member # 2797) on 03-09-2018, 04:19 PM:
Interesting that I've created DCP content using 2.09 and no problems using my Alchemy.
Wonder what happened then..
But, good to know an update is coming on and I plan on doing a donation for this great software.
Posted by Leo Enticknap (Member # 534) on 03-09-2018, 07:36 PM:
Carsten wrote that the problem was identified in 2.11.23, and fixed in 2.11.34, so 2.09 should be unaffected.
Posted by Todd Cornwall (Member # 2205) on 03-09-2018, 08:36 PM:
I curious, once you convert the content using DCP-o-Matic, can you just copy it to a USB drive? I see another program that only specializes in checking the integrity, and then "properly" putting it on a USB drive. Its really expensive, so I was looking around to see if something like that was even needed?
Posted by Leo Enticknap (Member # 534) on 03-09-2018, 10:05 PM:
Once you've created a DCP, using DCP-o-Matic or any other program, you have a number of options for ingesting it into your DCP server or TMS.
Almost all will accept ingestion via IP using FTP. If you want to use physical media, the two most commonly used forms are a hard drive in a CRU DX115 cartridge, or a USB hard drive or flash memory stick. In order to ensure that the DCP server will be able to read your drive, it should ideally be partitioned and formatted in compliance with the ISDCF specifications (MBR partition table, one single content partition occupying the entire drive, formatted as ext2 or ext3 and with an inode size of 128 bytes, and the DCP files in the top level folder or one down). To complicate matters, some servers and TMS systems will accept drives that are formatted in ways that are commonly used on personal computers (principally NTFS and HFS+), but aren't strictly "legal" for DCP distribution drives. If you try to ingest such a drive into any given server, you may get lucky, but there are no guarantees.
Posted by Carsten Kurz (Member # 5396) on 03-10-2018, 07:46 AM:
While the official recommendation is to use ext2 or ext3 discs, FAT32 or NTFS will work on all servers. At least so far I have never heard of a server rejecting NTFS. As long as you do this just for your own server/circuit, use what works for you. I came across rare issues with NTFS, but in the end, it turned out it was actually not NTFS, but the disc being partitioned with GPT/GUID. It needs to be MBR, single partition. Major operating systems nowadays default to using GPT/GUID when initializing discs, so, in general you have to reinit them using MBR. USB sticks will be MBR out of the box. FAT32 has a single file limit of 4GB, which you could run into with a short film. However, DCP-o-matic has an option to split reels to specific sizes if needed, and if you select 2 or 4 GB per reel, that will allow you to use FAT32 also for longer pieces. But in general, NTFS is okay.
Just don't start a professional dcp duplication service based on NTFS...
- Carsten
Posted by Leo Enticknap (Member # 534) on 03-10-2018, 10:37 AM:
As far as I know, Windows (up to and including 10) still uses MBR by default if the drive is 2TB or smaller. So if you hook such a drive to a Windows computer, and simply tell it to format it as NTFS via Windows Explorer, it should create a drive that will be legible to a DCP server that can read NTFS.
However, if the drive already has a GPT partition table, I suspect that Windows won't touch it, and will just reformat the partition. Using the Disk Management utility (enter diskmgmt.msc from a command prompt), though, you can force Windows to create an MBR partition table. I don't think Mac OS can at all, but I could be wrong on this.
If you are creating DCP distribution drives and need to have confidence that they will be legible in any server, a desktop Linux distro (e.g. Ubuntu or CentOS), and PartEd and mke2fs command lines is, IMHO, the best way to go. I don't know of any utility with a GUI that will enable you to create a totally ISDCF-compliant drive in one or two easy steps. GPartEd almost will, but it will only use an inode size of 256 bytes: there is no way of changing that.
Posted by Carsten Kurz (Member # 5396) on 03-10-2018, 04:52 PM:
All Mac OS X versions have a GUI option to choose MBR when initializing a disc in disc manager, there are three options: Apple partition table (PowerPC boot), MBR, GUID/GPT (Intel boot).
- Carsten
Posted by Todd Cornwall (Member # 2205) on 03-10-2018, 08:54 PM:
So...is a separate program needed to copy everything over to a flash drive? If I format it correctly, can I just copy it over to flash and it should be ok?
Posted by Monte L Fullmer (Member # 2797) on 03-11-2018, 01:15 AM:
All of my DCP created files are tranferred to a FAT32 thumbdrive, which we ingest into our LMS for the TMS to push to the assigned projectors.
Never had issues, but have to remember to have the audio at -10 prior to conversion.
I have two directories in my computer to work with this DCP program:
A directory named Video and a directory named DCP.
In the program preferences, i assign the completed file to be saved in the DCP directory. I copy my videos in the video directory.
I click New, give the new DCP a name and save that in the DCP directory.
Then, in the open file tab,I open up the video. I preview it in the pane to the right, then pause it.
I go in the video preferences and select the container I want this video to be converted in, which usually is the FLAT container, yet I've done 16.9 containers.
I go to the audio and set the audio to -10,for you don't want 0.0, for you'll just might blow the speakers out.
When all set, I hit the create DCP job and wait a few hours.
When done, I go to the DCP directory, find the created DCP, open that directory, find the actual directory that is part of the CPL Naming String and copy that directory to the thumbdrive for ingest.
.
Posted by Carsten Kurz (Member # 5396) on 03-11-2018, 08:22 AM:
quote: Todd Cornwall
So...is a separate program needed to copy everything over to a flash drive? If I format it correctly, can I just copy it over to flash and it should be ok?
Simple file/folder copying is okay. You only need to copy the single DCP folder that DCP-o-matic creates within the project folder, per default it will read something like <myfilmname>_-1_F_... etc depending on your ISDCF/DCNC naming settings. Forget about all the other files/folders in the project directory (like video, analysis, etc.). These are DCP-o-matic related files and are not part of the actual dcp. After the DCP has been created, choose 'Show DCP' from the 'Jobs' DropDown menu - it will open explorer/finder with exactly that dcp folder being selected, so just CTRL-C/-P or drag to destination drive.
Per default, DCP-o-matic will place project folder and the dcp within into your user directory, but you can relocate that standard path to anywhere else either on case-by-case, or by setting it in prefs.
- Carsten
Posted by Leo Enticknap (Member # 534) on 03-11-2018, 11:21 AM:
A very useful feature to have on DCP-o-Matic (or any other DCP authoring package, for that matter) would be a one-click "create distribution media" button. It would automatically partition and format the drive per ISDCF specs, then copy the DCP files into its top level folder, then dismount it.
For the Linux versions, this would be pretty easy to program, I'd have thought: the program would simply send the operating system a few command lines. It would be much more of a science project for the Windows and Mac versions, and I'm guessing that Carl would be reluctant to go down a road that leads to the package version for some operating systems having features that the one for others does not.
Posted by Carsten Kurz (Member # 5396) on 03-11-2018, 05:44 PM:
Carl is thinking about that for a long time - unfortunately, partitioning and formatting an ext2/ext3 drive needs raw access to the drive, and that should work on all supported platforms (well maybe you wouldn't need it for the Linux distributions). I guess it will come one day when Carl has found a safe way to do it - you don't want any existing drive to be touched by such a function, so it has to be absolutely idiot proof. Now think about the Linux method of accessing drives using the dev/sdx and mountpoint schemes...
- Carsten
Posted by Mike Blakesley (Member # 26) on 03-11-2018, 08:05 PM:
quote: Monte L Fullmer
I go to the audio and set the audio to -10,for you don't want 0.0, for you'll just might blow the speakers out.
From BluRays, I started at -6, then kept experimenting downward until finally settling on -1.5, which renders a DCP that's still somewhat softer than a typical studio DCP.
Posted by Monte L Fullmer (Member # 2797) on 03-12-2018, 05:51 AM:
And i'm working with MP4,AVI and MOV files...where these are recorded hot. Thus, i really have to scale down the audio track.
It all works great though, no matter what production techniques you use.
Plus, I do like making Audio only DCPs, and there, I scale the sound down to -25 for good background music output.
Posted by Leo Enticknap (Member # 534) on 03-12-2018, 09:47 AM:
The DCI spec for audio says that it should be normalized to -20dBFS. That is equal to unity (on the AES scale) on a cinema audio processor.
I've found that as a very rough rule of thumb for DCP-o-Matic, adjusting the audio gain such that the sustained peak is around -10 on the audio plot will result in a DCP that plays at around the same fader setting as a studio-mastered one. For example, in this illustration, if you usually play studio DCPs at around 6.5, you'd want to play this one at 4 to 4.5.
quote: Carsten Kurz
I guess it will come one day when Carl has found a safe way to do it - you don't want any existing drive to be touched by such a function, so it has to be absolutely idiot proof. Now think about the Linux method of accessing drives using the dev/sdx and mountpoint schemes...
Exactly, hence the reason this would be much easier to do in Linux than in Windows or Mac OS. One alternative approach would be a feature that creates a hard drive image file of a correctly partitioned and formatted drive, which the user then writes to blank media in a separate operation.
Posted by Carsten Kurz (Member # 5396) on 03-12-2018, 10:26 AM:
Note that DCP-o-matic offers EBU R128 audio loudness analysis. While 'LUFS' created from that analysis is not the same as LEQ(m), it is still very effective in setting the right audio levels for cinemas.
Neither channel peak nor channel RMS is suitable for estimating actual loudness from audio levels. RMS being a bit more useful than peak, though. Peak is actually only useful to identify clipping/distortion.
You need to enable R128 analysis in DCP-o-matic prefs. It will take a bit longer to analyze audio files, but it's worth it. LUFS is targeted at home users/broadcast, so it applies slightly different weighting functions than LEQ(m), but it still works for cinema applications. LUFS standard for broadcast is -23LUFS. In cinema, higher levels are expected/tolerated, so, something between -17 and -20 LUFS will usually work well. I have done a lot of testing around this, and it is dependable.
Why is there EBU R128/LUFS in DCP-o-matic, but not LEQ(m), when LEQ(m) is the proper loudness measurement method for cinema? Because the underlying ffmpeg framework that DCP-o-matic uses currently offers EBU R128 as a filter, and DCP-o-matic simply uses that available function. Writing your own LEQ(m) meter is a lot of work (and may need a Dolby license or NDA), so, as long as there is no LEQ(m) filter in ffmpeg, DCP-o-matic will use EBU R128/LUFS.
- Carsten
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2