Hi Carl, Good morning, I hope you are well.I have a couple of doubts…
1. When I deliver a DCP to the client on hard disk, do I have to copy the folder with the name to the hard disk root, for example Bewarethechild_FTR-1-25_F_NORSK-ES_51_2K_20200708_SMPTE_OV or just the contents of this folder?
2. What do I have to do to be able to check without any playback problems with DCP-o-matic 2 Player? My machine is powerful and playback is not smooth.
3. What program do you recommend for exporting subtitles (SRT) to import them into DCP-O-Matic 2?
Thank you very much and greetings.
Jordi Miró. 678442976
Hi Carl, I hope you are well. I need urgent help.
To my client, who is dedicated to film distribution, an international distributor says:
Could you please send me your lab's server certiifcate in order to issue the DKDM for the DCP?
No se que información le tengo que proprcionar. Me podrias aydar?
Muchas gracias!
Jordi Miró
been trying to convert out film into DCP but every time I do it keeps
telling me no assetmap?
macOS cataline
version: 10.15.2
I don't know what i'm doing wrong?
Really great idea!
Thanks,
Dave Roman
The Colour Closet
#101-511 West 14th Ave
Vancouver, BC, Canada
V5Z 2V7
639 317 7724
> On Mar 30, 2020, at 5:29 PM, dcpomatic-request(a)carlh.net wrote:
>
> Send DCPomatic mailing list submissions to
> dcpomatic(a)carlh.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
> or, via email, send a message with subject or body 'help' to
> dcpomatic-request(a)carlh.net
>
> You can reach the person managing the list at
> dcpomatic-owner(a)carlh.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DCPomatic digest..."
>
>
> Today's Topics:
>
> 1. Re: DCP-o-matic Disk Writer alpha test (Carl Hetherington)
> 2. Re: DCP-o-matic Disk Writer alpha test
> (cjflynn(a)digitaltesttools.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2020 01:14:09 +0100 (BST)
> From: Carl Hetherington <cth(a)carlh.net>
> To: "audiovisual(a)t-online.de" <audiovisual(a)t-online.de>
> Cc: "dcpomatic(a)carlh.net" <dcpomatic(a)carlh.net>
> Subject: Re: [DCP-o-matic] DCP-o-matic Disk Writer alpha test
> Message-ID: <alpine.DEB.2.21.2003310105070.1218(a)main.carlh.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
>> Can you tell us how this works/what it is doing in detail?
>
> There is some platform-specific code to find available drives and open
> them as devices that DCP-o-matic can write raw data to. Then there is a
> library called lwext4 (https://github.com/gkostka/lwext4) (that I have
> tweaked a little) which can make an ext2 filesystem given a place to write
> the raw data.
>
> So the DCP-o-matic Disk Writer just asks for a DCP and a drive, then
> formats the drive as ext2 with the required inode size, copies the data
> and verifies it.
>
> It seems to work on Windows and Linux and I am just working on the Mac
> version.
>
> The two main concerns I have are:
>
> 1. does it destroy users' data?
> 2. does it *always* either a) make a valid DCP drive or b) give an error.
>
> If we are confident that (1) happens rarely and (2) happens mostly then we
> will probably have a useful tool. TBH one of the main motivations here is
> to remove a source of error that can be blamed on DCP-o-matic, and to
> simplify the explanation of the DCP-making process to truly be "put your
> file in, click the button, get a drive out".
>
> All the best,
> Carl
>
>
>
>>
>> - Carsten
>>
>>
>> -----Original-Nachricht-----
>> Betreff: [DCP-o-matic] DCP-o-matic Disk Writer alpha test
>> Datum: 2020-03-30T00:35:45+0200
>> Von: "Carl Hetherington via DCPomatic" <dcpomatic(a)carlh.net>
>> An: "dcpomatic(a)carlh.net" <dcpomatic(a)carlh.net>
>>
>> Hi all,
>>
>> I'm hopefully not-too-far (TM) away from having a very alpha-quality
>> version of a "disk writer" tool for DCP-o-matic. This is a thing which
>> can format a drive as EXT2 and copy a DCP onto it from
>> Linux/macOS/Windows.
>>
>> Since the potential for disaster is fairly high with this tool (i.e.
>> unrecoverably destroyed hard disk partitions) I am hoping to find some
>> brave and interested parties to test it out in a sort of "closed beta"
>> arrangement, rather than making it available to everybody in the normal
>> test version.
>>
>> If you are interested in helping out with testing, drop me a line! All
>> that's really required is an understanding that the software might destroy
>> any data that happens to be on any drive connected to the computer that
>> you run it on. So if you have an old machine that you could tolerate
>> re-installing, that would be ideal! It doesn't need any great CPU power.
>>
>> If you have access to a cinema to test your copied drives, even better!
>>
>> I hope everybody is keeping as well as can be expected given the current
>> state of the world.
>>
>> Kind regards,
>> Carl
>>
>>
>> _______________________________________________
>> DCPomatic mailing list
>> DCPomatic(a)carlh.net
>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>> ?
>>
>> _______________________________________________
>> DCPomatic mailing list
>> DCPomatic(a)carlh.net
>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Mar 2020 17:28:56 -0700
> From: "cjflynn(a)digitaltesttools.com" <cjflynn(a)digitaltesttools.com>
> To: Carl Hetherington <cth(a)carlh.net>
> Cc: "audiovisual(a)t-online.de" <audiovisual(a)t-online.de>,
> "dcpomatic(a)carlh.net" <dcpomatic(a)carlh.net>
> Subject: Re: [DCP-o-matic] DCP-o-matic Disk Writer alpha test
> Message-ID:
> <75956F52-8767-4467-946C-252982593D1E(a)digitaltesttools.com>
> Content-Type: text/plain; charset="utf-8"
>
> My spare Mac situation might be great for this since it is booting off an external USB. So, if the program will confuse and wipe out anything, it will be a good target. I?ll make certain to make an image of it for when you are ready for testing!
>
> Best in return,
> C J
>
>> On Mar 30, 2020, at 5:14 PM, Carl Hetherington via DCPomatic <dcpomatic(a)carlh.net> wrote:
>>
>> Hi all,
>>
>>> Can you tell us how this works/what it is doing in detail?
>>
>> There is some platform-specific code to find available drives and open
>> them as devices that DCP-o-matic can write raw data to. Then there is a
>> library called lwext4 (https://github.com/gkostka/lwext4 <https://github.com/gkostka/lwext4>) (that I have
>> tweaked a little) which can make an ext2 filesystem given a place to write
>> the raw data.
>>
>> So the DCP-o-matic Disk Writer just asks for a DCP and a drive, then
>> formats the drive as ext2 with the required inode size, copies the data
>> and verifies it.
>>
>> It seems to work on Windows and Linux and I am just working on the Mac
>> version.
>>
>> The two main concerns I have are:
>>
>> 1. does it destroy users' data?
>> 2. does it *always* either a) make a valid DCP drive or b) give an error.
>>
>> If we are confident that (1) happens rarely and (2) happens mostly then we
>> will probably have a useful tool. TBH one of the main motivations here is
>> to remove a source of error that can be blamed on DCP-o-matic, and to
>> simplify the explanation of the DCP-making process to truly be "put your
>> file in, click the button, get a drive out".
>>
>> All the best,
>> Carl
>>
>>
>>
>>>
>>> - Carsten
>>>
>>>
>>> -----Original-Nachricht-----
>>> Betreff: [DCP-o-matic] DCP-o-matic Disk Writer alpha test
>>> Datum: 2020-03-30T00:35:45+0200
>>> Von: "Carl Hetherington via DCPomatic" <dcpomatic(a)carlh.net>
>>> An: "dcpomatic(a)carlh.net" <dcpomatic(a)carlh.net>
>>>
>>> Hi all,
>>>
>>> I'm hopefully not-too-far (TM) away from having a very alpha-quality
>>> version of a "disk writer" tool for DCP-o-matic. This is a thing which
>>> can format a drive as EXT2 and copy a DCP onto it from
>>> Linux/macOS/Windows.
>>>
>>> Since the potential for disaster is fairly high with this tool (i.e.
>>> unrecoverably destroyed hard disk partitions) I am hoping to find some
>>> brave and interested parties to test it out in a sort of "closed beta"
>>> arrangement, rather than making it available to everybody in the normal
>>> test version.
>>>
>>> If you are interested in helping out with testing, drop me a line! All
>>> that's really required is an understanding that the software might destroy
>>> any data that happens to be on any drive connected to the computer that
>>> you run it on. So if you have an old machine that you could tolerate
>>> re-installing, that would be ideal! It doesn't need any great CPU power.
>>>
>>> If you have access to a cinema to test your copied drives, even better!
>>>
>>> I hope everybody is keeping as well as can be expected given the current
>>> state of the world.
>>>
>>> Kind regards,
>>> Carl
>>>
>>>
>>> _______________________________________________
>>> DCPomatic mailing list
>>> DCPomatic(a)carlh.net
>>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>>> ?
>>>
>>> _______________________________________________
>>> DCPomatic mailing list
>>> DCPomatic(a)carlh.net
>>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>> _______________________________________________
>> DCPomatic mailing list
>> DCPomatic(a)carlh.net <mailto:DCPomatic@carlh.net>
>> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic <http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic>
>
Hi all,
I'm hopefully not-too-far (TM) away from having a very alpha-quality
version of a "disk writer" tool for DCP-o-matic. This is a thing which
can format a drive as EXT2 and copy a DCP onto it from
Linux/macOS/Windows.
Since the potential for disaster is fairly high with this tool (i.e.
unrecoverably destroyed hard disk partitions) I am hoping to find some
brave and interested parties to test it out in a sort of "closed beta"
arrangement, rather than making it available to everybody in the normal
test version.
If you are interested in helping out with testing, drop me a line! All
that's really required is an understanding that the software might destroy
any data that happens to be on any drive connected to the computer that
you run it on. So if you have an old machine that you could tolerate
re-installing, that would be ideal! It doesn't need any great CPU power.
If you have access to a cinema to test your copied drives, even better!
I hope everybody is keeping as well as can be expected given the current
state of the world.
Kind regards,
Carl
Dear Carl,
Our customer Mrs. Deickert is working with your wonderful tool to create frequently DCPs for her cinema.
We created a remote working solution for, the Sony Server is connected to a small PC with is continuosly connected to the Internet. First we tried Apple iCloud synchronization to bring the DCP files from her Macbook Pro to the Windows PC, now we switched to GDrive.
Currently we face the issues that the GDrive sync app does not sync two files which are technically identical but have a different naming. I speak about both the j2c and the file in the movie folder. I do not know why during the export you save the video file with two diffenent names. Is there a way to disable the second video export in the movie folder? As GDrive is skipping the j2c movie file, the server does not allow to ingest the DCP in a correct way. Do you have any idea?
Thank you and best regards from Munich
René
__________________________________________________
René Wagner, M.Sc.
Specialist for Virtual Reality, Multimedia, High-Res Projection and Digital Cinema systems
Tel: +49 89 958 23 324 Videocation GmbH
Fax: +49 89 958 23 299 Schatzbogen 50-52
Mobile: +49 162 61 22 714 DE-81829 München
r.wagner(a)videocation.com<mailto:r.wagner@videocation.com> Registergericht München HRB 555 80
www.videocation.com<http://www.videocation.com/> Geschäftsführer Carl Nedeltschev, Ralf P. Pfeffer
Hello from Berlin, Germany.
I need help with exporting the necessary data out of dcpomatic in order for a posthouse to make me a DKDM that I can use, to create KDMs for festivals. I’m the director of that movie and we agreed to outsource this process from the posthouse to me to safe a lot of money and time for the KDM creation.
I exported the „KDM Encryption Certificate“ as explained in the manual and sent it to the company. They said, they need also a pem file. I didn’t know which file was right, so I exported everything to them what I found under the keys tab. 4 or 5 files. Then they finally made me the DKDM. But when I try to open in in the KDM Creator it failes and warns, that it maybe was made with the wrong certificate.
We are lost. Can you help me? Which files are exactly needed in order to create a DKDM and where do I export them?
Thanks, Martin
___
Martin Busker
Regisseur und Autor
Prenzlauer Allee 203
10405 Berlin
+49 179 2319461
mail(a)martin-busker.de
www.martin-busker.de
Hi all.
I'm making a DCP of compilation of short films. Half the films are 4K
source, the other half are 2K.
If I make the DCP as 4K, the 2K films will get uprezzed to 4K, but the
majority of cinemas will probably only have 2K projectors, so will
downres to 2K again.
Will that result in the 2K films looking worse than they would have if
the DCP was made 2K in the first place?
i.e. This would involve 2 translations: (1) DCP-o-matic 2K -> 4K scaling
and (2) J2K decoding discarding a resolution level. Are the two
translations a good mirror of each other? Or do they work in different
ways so it could result in the 2K film looking less sharp than if DCP
had been encoded in 2K in the first place?
Obviously, the 4K films would look less sharp if encoded as 2K. But what
I'm wondering is whether I need to make both 2K and 4K DCPs so the films
can be presented optimally in all cinemas, or whether just a 4K DCP will
cover all cases.
Hope this makes some kind of sense!
Jim
So, maybe it was indeed Resolve. There are other options as well, Adobe products, JPEG2000 plugins for Adobe products.
- Carsten
Am 26.01.2020 um 16:34 schrieb lilian:
> It seems the mxf was only wrapped with OpenDCP:
> asdcp-info -i -d returns
>
> SMPTE 429 file essence type is JPEG 2000 pictures, (6737 edit units).
> ProductUUID: 43059a1d-0432-4101-b83f-736815acf31d
> ProductVersion: 0.30.0
> CompanyName: OpenDCP
> ProductName: OpenDCP
> EncryptedEssence: No
> AssetUUID: 1ee2949c-c2ef-46f5-b5c5-738109994496
> Label Set Type: SMPTE
> AspectRatio: 1998/1080
> EditRate: 24/1
> SampleRate: 24/1
> StoredWidth: 1998
> StoredHeight: 1080
> Rsize: 3
> Xsize: 1998
> Ysize: 1080
> XOsize: 0
> YOsize: 0
> XTsize: 1998
> YTsize: 1080
> XTOsize: 0
> YTOsize: 0
> ContainerDuration: 6737
> -- JPEG 2000 Metadata --
> ImageComponents:
> bits h-sep v-sep
> 12 1 1
> 12 1 1
> 12 1 1
> Scod: 1
> ProgressionOrder: 4
> NumberOfLayers: 1
> MultiCompTransform: 1
> DecompositionLevels: 5
> CodeblockWidth: 3
> CodeblockHeight: 3
> CodeblockStyle: 0
> Transformation: 0
> Precincts: 6
> precinct dimensions:
> 1: 128 x 128
> 2: 256 x 256
> 3: 256 x 256
> 4: 256 x 256
> 5: 256 x 256
> 6: 256 x 256
> Sqcd: 66
> SPqcd: 972096f096f096c08f008f008ee087508750876870057005704777d377d37762
>
> j2c-test does not give the same result between Jim's DCP and J2K created with OpenDCP.
>
> Jim's DCP:
> SIZ:
> Rsize: 3
> Xsize: 1998
> Ysize: 1080
> XOsize: 0
> YOsize: 0
> XTsize: 1998
> YTsize: 1080
> XTOsize: 0
> YTOsize: 0
> Csize: 3
> Components
> 0: 11, 1, 1
> 1: 11, 1, 1
> 2: 11, 1, 1
> COD:
> ProgOrder: CPRL
> Layers: 1
> DecompLevels: 5
> CodeBlockWidth: 32
> CodeBlockHeight: 32
> CodeBlockStyle: 0
> Transformation: 9/7
> QCD:
> QuantizationType: scalar expounded
> GuardBits: 4
> SPqcd: 4
> 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P.
> 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> Unprocessed marker - SOT: Start of tile-part
> Processed 11 JPEG 2000 marker items.
>
> OPEN DCP 0.30.0:
> SIZ:
> Rsize: 3
> Xsize: 1920
> Ysize: 1080
> XOsize: 0
> YOsize: 0
> XTsize: 1920
> YTsize: 1080
> XTOsize: 0
> YTOsize: 0
> Csize: 3
> Components
> 0: 11, 1, 1
> 1: 11, 1, 1
> 2: 11, 1, 1
> COD:
> ProgOrder: CPRL
> Layers: 1
> DecompLevels: 5
> CodeBlockWidth: 32
> CodeBlockHeight: 32
> CodeBlockStyle: 0
> Transformation: 9/7
> QCD:
> QuantizationType: scalar expounded
> GuardBits: 4
> SPqcd: 4
> 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P.
> 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> COM:OpenDCP
> Unprocessed marker - SOT: Start of tile-part
> Processed 12 JPEG 2000 marker items.
>
> DOM 2.14.17:
> SIZ:
> Rsize: 3
> Xsize: 1998
> Ysize: 1080
> XOsize: 0
> YOsize: 0
> XTsize: 1998
> YTsize: 1080
> XTOsize: 0
> YTOsize: 0
> Csize: 3
> Components
> 0: 11, 1, 1
> 1: 11, 1, 1
> 2: 11, 1, 1
> COD:
> ProgOrder: CPRL
> Layers: 1
> DecompLevels: 5
> CodeBlockWidth: 32
> CodeBlockHeight: 32
> CodeBlockStyle: 0
> Transformation: 9/7
> QCD:
> QuantizationType: scalar expounded
> GuardBits: 4
> SPqcd: 4
> 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P.
> 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb
> COM:libdcp
> Unprocessed marker - SOT: Start of tile-part
> Processed 8 JPEG 2000 marker items.
>
> Le dim. 26 janv. 2020 à 15:13, audiovisual--- via DCPomatic <dcpomatic(a)carlh.net> a écrit :
>
> I am not fluent in J2K, but to me it looks as if that codestream at least tries to be DCI compliant:
>
> ---
> Cinema2K profile: This option generates a codestream compliant to the Digital cinema specifications for a 2K resolution content. The value given is the frame rate which can be 24 or 48 fps. The main specifications of the JPEG Profile-3 (2K Digital Cinema Profile) are * Image size = 2048 x 1080 (at least one of the dimensions should match 2048 x 1080) * Single tile * Wavelet transform levels = Maximum of 5 * Wavelet filter = 9-7 filter * Codeblock size = 32 x 32 * Precinct size = 128 x 128 (Lowest frequency subband), 256 x 256 (other subbands) * Maximum Bit rate for entire frame = 1302083 bytes for 24 fps, 651041 bytes for 48fps * Maximum Bit rate for each color component= 1041666 bytes for 24 fps, 520833 bytes for 48fps * Tile parts = 3; Each tile part contains data necessary to decompress one 2K color component * 12 bits per component.
> ---
>
> It would be interesting to see the same J2C-test output for a current DCP-o-matic output file in comparison.
>
> Jim - is the metadata of the original DCP still available?
> Wondering wether the original MXF file contains some header data that may lead to the origin of the files? Although it is quite probable that it would just lead to OpenDCP.
>
> It may still be interesting to find the reason for this, but, in general, when I come across a non-working DCP, I first try to rewrap, and if that also fails, try to re-encode, and then forget about it. J2K and MXF is complex enough, and finding the actual cause will usually get you nowhere, at least when 'old' software has been used. A developer of current software of course, confronted with such an issue should be highly interested.
>
>
>
> ---------------
>
>
> I checked j2c structure with j2c-test but I do not know how to analyse the 'Unprocessed marker':
> SIZ:
> Rsize: 3
> Xsize: 1998
> Ysize: 1080
> XOsize: 0
> YOsize: 0
> XTsize: 1998
> YTsize: 1080
> XTOsize: 0
> YTOsize: 0
> Csize: 3
> Components
> 0: 11, 1, 1
> 1: 11, 1, 1
> 2: 11, 1, 1
> COD:
> ProgOrder: CPRL
> Layers: 1
> DecompLevels: 5
> CodeBlockWidth: 32
> CodeBlockHeight: 32
> CodeBlockStyle: 0
> Transformation: 9/7
> QCD:
> QuantizationType: scalar expounded
> GuardBits: 4
> SPqcd: 4
> 000000: 20 96 f0 96 f0 96 c0 8f 00 8f 00 8e e0 87 50 87 .............P.
> 000001: 50 87 68 70 05 70 05 70 47 77 d3 77 d3 77 62 P.hp.p.pGw.w.wb
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> Unprocessed marker - COC: Coding style component
> Unprocessed marker - QCC: Quantization component
> Unprocessed marker - SOT: Start of tile-part
> Processed 11 JPEG 2000 marker items.
>
> Le sam. 25 janv. 2020 à 23:07, Carl Hetherington via DCPomatic <dcpomatic(a)carlh.net> a écrit :
> Hi Jim
>
> It might be interesting to see if DCP-o-matic will happily make a new DCP
> out of it with "force J2K re-encode" ticked.
>
> Best
> Carl
>
> On Sat, 25 Jan 2020, Jim Dummett via DCPomatic wrote:
>
> > Hi all.
> >
> > Anyone out there have access to a Wailua or recent version of EasyDCP Player+,
> > and be willing to run a DCP through it for validation?
> >
> > This DCP is a 3 minute short which failed playback at a London cinema
> > recently. The fault was that picture and sound cut out (screen black, silence)
> > for a couple of seconds and then playback resumed, but it skipped forwards by
> > about 1 minute. This behaviour was replicated on two different servers at this
> > cinema, although weirdly it played back faultlessly at another cinema.
> >
> > The disturbing thing is that I cannot find any fault with the DCP with the
> > tools I have available. I would really like to find out what the fault is so I
> > can add tools to our workflow to catch similar faults in future.
> >
> > NB This DCP came from an unknown external source and was made with OpenDCP.
> > However, we rewrapped it with DCP-o-matic (without force J2K re-encode) and
> > the problem persisted in that rewrapped DCP.
> >
> > If anyone is able to help, would be amazing.
> >
> > Many thanks,
> >
> > Jim
> >
> >
> >
> > _______________________________________________
> > DCPomatic mailing list
> > DCPomatic(a)carlh.net
> > http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
> >
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
>
> _______________________________________________
> DCPomatic mailing list
> DCPomatic(a)carlh.net
> http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
Hi all.
Anyone out there have access to a Wailua or recent version of EasyDCP
Player+, and be willing to run a DCP through it for validation?
This DCP is a 3 minute short which failed playback at a London cinema
recently. The fault was that picture and sound cut out (screen black,
silence) for a couple of seconds and then playback resumed, but it
skipped forwards by about 1 minute. This behaviour was replicated on two
different servers at this cinema, although weirdly it played back
faultlessly at another cinema.
The disturbing thing is that I cannot find any fault with the DCP with
the tools I have available. I would really like to find out what the
fault is so I can add tools to our workflow to catch similar faults in
future.
NB This DCP came from an unknown external source and was made with
OpenDCP. However, we rewrapped it with DCP-o-matic (without force J2K
re-encode) and the problem persisted in that rewrapped DCP.
If anyone is able to help, would be amazing.
Many thanks,
Jim
