DDP file info differs from CD info

[Jacek Gawlowski]

Hi!
I recently had my master rejected by the pressing plant.
We sent both the DDP 2.0 file (from Sequoia 7.23) and the audio CD.
The plant compared them and informed us that they differ,
therefore pressing will not start untill we clear this problem.
Anyone have any idea why they may differ?

Jacek

[mrlouie]

wouldnt the plant have told you how they were different ????

why you send both ?

[Jacek Gawlowski]

Originally Posted by mrlouie

wouldnt the plant have told you how they were different ????

why you send both ?

They asked for both.
They only sent this attachment.

J

[bob katz]

Originally Posted by Jacek Gawłowski

Hi!
I recently had my master rejected by the pressing plant.
We sent both the DDP 2.0 file (from Sequoia 7.23) and the audio CD.
The plant compared them and informed us that they differ,
therefore pressing will not start untill we clear this problem.
Anyone have any idea why they may differ?

Jacek

You need to find someone knowledgeable at the plant who can explain those discrepancies in more detail. I'll bet the errors (discrepancies) are at the track marks (PQ). This is not a content comparison or audio comparison at all. The discrepancies could be completely trivial and describe a weakness in how you are writing CDs.

Does Sequoia have a method of reloading a CD or a DDP back into an EDL and showing you the PQ? If so, you can compare the PQ points yourself via a loadback process.

Keep us posted, Jacek, sorry for your troubles.

BK

[asbury media]

Hey Jacek,

Not sure the cause of your problem but I would be concerned. The plant ran your DDP and CD through "Eclipse Image Verify" and it clearly indicates that the audio content is indeed different. The duration of the discrepancies (I'm guessing here) seems to last for the entire length of the track and does not resolve until the next track change. Compare the timings in the Eclipse log and see if they line-up with your CD track sheet.

When working with DDP file sets I find it best to generate and include md5 check-sum files. The plant can then verify that the DDP image is exactly the same as when you created the md5 files. This is an easy way to insure the data integrity of the DDP and an easy way to manage project archive verification.

Let us know what you find when you get your pre-masters back. Could have been a slight level change or dither setting? Good luck!

Tom "Curly" Ruff

[Jacek Gawlowski]

Originally Posted by bob katz

You need to find someone knowledgeable at the plant who can explain those discrepancies in more detail. I'll bet the errors (discrepancies) are at the track marks (PQ). This is not a content comparison or audio comparison at all. The discrepancies could be completely trivial and describe a weakness in how you are writing CDs.

Does Sequoia have a method of reloading a CD or a DDP back into an EDL and showing you the PQ? If so, you can compare the PQ points yourself via a loadback process.

Keep us posted, Jacek, sorry for your troubles.

BK

Thanks for suggestions Bob.
Sequoia does have a method of reloading a DDP back into an EDL and showing the PQ.I did that and the results matched.

Anyway,I foud out today that the plant did not use my CD as a reference.Instead they took the copy of a copy they received from the record company a bit earlier.
This explains perhaps why these were not identical.I'm not sure who did the copy and why,however I will ask them to check MY DISC against the DDP once again.

Jacek

[bob katz]

Originally Posted by asbury media

Hey Jacek,

Not sure the cause of your problem but I would be concerned. The plant ran your DDP and CD through "Eclipse Image Verify" and it clearly indicates that the audio content is indeed different.

Dear Asbury:

Thanks for clarifying what the Eclipse readout was saying. I was wrong about that. But isn't it true that if there is an offset between the location of the PQ marks on his CD and the PQ marks on his DDP, even if they are PERFECT AUDIO CLONES, the Eclipse verify will show a difference? After all, it is only a machine and it is programmed to say that at time X there should be a zero, but not smart enough to recognize that zero may be located at time X minus 3 samples, for example.

I'm just offering that hypothesis. Only because the data integrity of Sequoia is very high and it is likely that he cut both the DDP and the CD from the same image file. They couldn't possibly differ for 3 minutes' time unless, perhaps there is a timing offset. OR, if he by accident he put some processing or dithering on the DDP that was not on the CDR. That's why a null test should now be performed.

BK

[mrlouie]

Originally Posted by Jacek Gawłowski

Anyway,I foud out today that the plant did not use my CD as a reference.Instead they took the copy of a copy they received from the record company a bit earlier.
This explains perhaps why these were not identical.I'm not sure who did the copy and why,however I will ask them to check MY DISC against the DDP once again.

Jacek

what a drag .. kinda like when they shoot a video with a rough mix before the song is done, then they get the mastered final version and things dont match.

I've never had a label ask for a cd to be sent with the master to the plant to check against each other.. interesting.

Hope it all ends up being ok.

[asbury media]

Ah yes, the label factor.

Bob - The Image Verify log should indicate if the PQ points are off between the two source files. I say "should" indicate because the behavior rules in Eclipse can be user set or left at the default. Eclipse Data offers a pretty sophisticated suite of applications and with Image Verify it uses logic to determine if the same series of data is present at the source (DDP) and target (CD) but is offset, and tries to sync the data following the (red) book rules of the source image. The log will then display all discrepancies as defined by the user.

tr

[bob katz]

Originally Posted by asbury media

Ah yes, the label factor.

Bob - The Image Verify log should indicate if the PQ points are off between the two source files. I say "should" indicate because the behavior rules in Eclipse can be user set or left at the default. Eclipse Data offers a pretty sophisticated suite of applications and with Image Verify it uses logic to determine if the same series of data is present at the source (DDP) and target (CD) but is offset, and tries to sync the data following the (red) book rules of the source image. The log will then display all discrepancies as defined by the user.

tr

Now that's real smart! I had no idea how smart the Eclipse suite is.

BK