R/E/P Community

R/E/P => Mastering Dynamics => Topic started by: tbridge on March 26, 2011, 06:57:02 am

Title: DDP fail
Post by: tbridge on March 26, 2011, 06:57:02 am
For a couple of decades, I've been creating DDP files on Sadie and delivering on Exabyte, but the tape machine is slowly giving up the ghost - so, for my latest job, I decided to use Sonoris' DDP Creator, a great program which creates the whole fileset along with CD-Text and also the MD5 checker. You can also upload the fileset from within the program.

My client is very fastiduous about ISRCs and CD-Text and listens to and checks every stage of the process. Over the years, he has had masters delivered to him on CD, but he has come to me for his latest project, and I persuaded him to go the DDP route - he struggled with the concept, but after speaking to his broker, finally agreed. I cut him a CD directly from the image file created in Sonoris, which he auditioned and gave the green light - then I uploaded the fileset to his broker's ftp site (I'd rather have sent it directly to the plant, but you know how brokers can be coy about where they are pressing!). 3 or 4 days later, my client received several thousand pressings - each one with a minute's silence in the first track.

The image file on my computer is intact, but I downloaded the file from the ftp server, and that indeed has a minute's silence. I have no idea how this can happen without the checker spotting it. Is there any point in me downloading the checker from the server and running that, or have I got the wrong idea entirely?

Thanks for any advice you may be able to share, even if it's only a virtual man-hug  ;)

Tony
Title: Re: DDP fail
Post by: tbridge on March 26, 2011, 07:20:36 am
fwiw, I've just downloaded the folder from the ftp server, run the MD5 checker, and it reports an error...
Title: Re: DDP fail
Post by: bblackwood on March 26, 2011, 08:03:45 am
Ahh, so the uploaded file contained the error?  Or was the file corrupted during the upload? Did you use any sort of file compression (zip, etc)?
Title: Re: DDP fail
Post by: bkuijt on March 26, 2011, 08:57:11 am
Mr. Bridge!
So nice to see you here!
Of course this happens with the most cautious and suspicious client.... typical...

...editing my post again, need to learn how to read better....

If the MD5 check fails it indicats that neither the broker nor the plant ran the check!
That's pretty silly if they do support online delivery.

Like Brad suggests, delivering a .zip or .rar packed archive is safer.

Hope you'll solve it!
Bests, Bastiaan
Title: Re: DDP fail
Post by: tbridge on March 26, 2011, 09:09:58 am
Hey Bast, how are you?

Well, the file that exists on my computer is what I burnt the ref CDs from, with no problem. I can listen to it now, and it's intact. And that is the file that I uploaded to the server, so I can only assume that it was the upload process that corrupted the file. As I say, the MD5 check (from the server) fails... but if I run that checker against the original file, it passes.

So, that confirms (I think! my head's spinning...) what I really knew, that the two files are different. It's the 'why' that I don't understand yet :(
Title: Re: DDP fail
Post by: bkuijt on March 26, 2011, 09:22:36 am
I need to learn how to read better...

Modified my post just while you typed a reply.
At first I assumed the disc had additional silence like someone modified it. I had that recently, but with a burned CDR master..

If the MD5 check fails it indicates that neither the broker nor the plant ran the check!
That's pretty silly if they do support online delivery.

Did their delivery specification say it should have been packed in some sort of archive?
If not, then it's just as much their mistake not to verify delivered content!

Hope you're doing well apart from this issue!
Bests, Bastiaan
Title: Re: DDP fail
Post by: jdg on March 26, 2011, 02:12:16 pm
i find it odd that the corrupt DDP caused 1m of silence.

if it was corrupt, the is a 99.999% chance it just would not load in at all.

how did the plant intake the DDP? sounds like something happened after intake
Title: Re: DDP fail
Post by: ggidluck on March 27, 2011, 04:14:39 pm
So, that confirms (I think! my head's spinning...) what I really knew, that the two files are different. It's the 'why' that I don't understand yet :(

FTP does not do checksums on each packet and resend corrupt packets. As a defense, if you zip (or rar) the file, the program which opens it will detect an error if the embedded zip checksum does not match the original. Make sense?


 
Title: Re: DDP fail
Post by: Pieter Stenekes on March 28, 2011, 04:30:54 am
if you zip (or rar) the file

or you can download the image back and check the md5 yourself before giving clearance to the plant
Title: Re: DDP fail
Post by: tbridge on March 28, 2011, 05:27:44 am
Pieter, I did that over the weekend, and sure enough the checker fails, but passes the original file. I agree with jdg that I would have thought a corrupt file would just not play.

check the md5 yourself before giving clearance to the plant
it seems that this is the way forward in future...

I find it sad and frustrating that we have to jump through yet another hoop just to cover the incompetence of others - should the mastering engineer have to do QC for the plant too? >:(
Title: Re: DDP fail
Post by: phonon on March 28, 2011, 08:45:24 am
Are you saying that the FTP process corrupted the DDPi only by adding a minute of silence to the program that shouldn't have been there?    Isn't it rather a smoking gun that the factory edited the DDPi?


Andrew
Title: Re: DDP fail
Post by: tbridge on March 28, 2011, 11:28:06 am
Andrew, no not added... 30 seconds into the first track, the music disappears for a whole 60 seconds, while the CD display keeps ticking over. The only way that could happen, I should think, is if I created an edl with 60 seconds of silence in the first track, but the MD5 I included with the uploaded DDP set passes the master edl, which of course is intact. It doesn't pass the image file on the ftp server.

That doesn't make the bad image file the fault of the plant - where their fault lies is in not running the checker, which would have spotted a bad file, which I could then have re-uploaded.  :'(

Title: Re: DDP fail
Post by: Table Of Tone on March 28, 2011, 04:22:22 pm
or you can download the image back and check the md5 yourself before giving clearance to the plant
That's what I'd do!

What are your thoughts on putting a couple DDP's (double CD release) on a DVDR?
Should I zip each one?
Title: Re: DDP fail
Post by: Treelady on March 28, 2011, 11:13:11 pm
(I think Brian from DM always says the following): When you submit a DDP, add the checksum file inside the folder, compress the entire folder (.zip or .rar) and send that to the plant. 

When they open it, if the file won't de-compress, they know there is an issue.  If the file does de-compress, the plant should still check the MD5 file to make sure the DDP you sent is the one they have. 

For those of you who upload a file then download it to recheck, that's good, except if the plant has an issue on their download from their FTP server to their local machines (not all FTP boxes on onsite.  If the FTP server is outsourced, the could have transmission errors from the FTP Server to the Plant's production sever.) Your lawyer will be happy that you put the correct file on the FTP server, but the client needs it to get all the way to the Plant's production server.

Ultimately, the plant has to assume some level of professionalism and accept responsibility for what they produce.  Just as many mastering engineers add extra hours (often un-billed) to double check that DDPs are correct, the plant needs to put forth the effort to protect the interests of their clients.

This is a rough situation, and I wouldn't wish it on anyone.

Best,
GH
Title: Re: DDP fail
Post by: lowland on March 29, 2011, 03:08:26 am
What are your thoughts on putting a couple DDP's (double CD release) on a DVDR?
Should I zip each one?
Not Pieter, but this cropped up here a few years ago and I was told 'only one master per disc' at the time, so a double CD = 2 x DVD DDP masters. Not sure why this is, perhaps it's a potential source of confusion at the factory - I've done it since with doubles (or more) and there's been no problem.
Title: Re: DDP fail
Post by: Allen Corneau on March 29, 2011, 08:57:29 am
(I think Brian from DM always says the following): When you submit a DDP, add the checksum file inside the folder, compress the entire folder (.zip or .rar) and send that to the plant.

This is what I've been doing lately and no problems so far.
Title: Re: DDP fail
Post by: phonon on March 30, 2011, 09:16:05 am
Andrew, no not added... 30 seconds into the first track, the music disappears for a whole 60 seconds, while the CD display keeps ticking over. The only way that could happen, I should think, is if I created an edl with 60 seconds of silence in the first track, but the MD5 I included with the uploaded DDP set passes the master edl, which of course is intact. It doesn't pass the image file on the ftp server.

Thanks for clarifying, Tony...  However, I should have thought that the MD5 you created was created to be a checksum of the premaster DDP image you sent (the one that is, presumably, still on your hdd) - _not_ a bit-string of the edit decision list in the DAW, which would have a different hexcode expression from even a perfectly Dumped premaster thereof, yes?



That doesn't make the bad image file the fault of the plant - where their fault lies is in not running the checker, which would have spotted a bad file, which I could then have re-uploaded.  :'(

Indeed...   they should not have proceeded until either you gave them the green light on the redownloaded DDP or they, at least, checked the checksum, themselves, against what the image copy they had.   Otherwise, it is they who leaped without looking first - not you...

They allegedly said, "Why did the engineer send an MD5...?"    If this is the case, then they should be trained on the vagaries of FTP.


Of course, perhaps MD5 is also somewhat unreliable.   Although it may be that the only issue is the ability for two different files to generate the same hexcode and not for the same file to generate two different hexcodes...

from Wiki:
"US-CERT of the U. S. Department of Homeland Security said MD5 "should be considered cryptographically broken and unsuitable for further use,"[9] and most U.S. government applications now require the SHA-2 family of hash functions.[10]"



Andrew


Title: Re: DDP fail
Post by: tbridge on March 30, 2011, 10:06:58 am
<snip>..I should have thought that the MD5 you created was created to be a checksum of the premaster DDP image you sent (the one that is, presumably, still on your hdd)... yes?

yes indeed, but that also includes checking the PQ, which has not been affected by a whacking great silence in Track One.

And I agree with everything else you say, except that MD5 still seems to be the industry norm for us audio engineers, maybe the CIA needs something more robust.
Title: Re: DDP fail
Post by: bkuijt on March 30, 2011, 01:08:43 pm
Of course, perhaps MD5 is also somewhat unreliable.   Although it may be that the only issue is the ability for two different files to generate the same hexcode and not for the same file to generate two different hexcodes...

from Wiki:
"US-CERT of the U. S. Department of Homeland Security said MD5 "should be considered cryptographically broken and unsuitable for further use,"[9] and most U.S. government applications now require the SHA-2 family of hash functions.[10]"

This Wiki quote is reffering to the fact that it is not impossible to crack passwords generated with the MD5 hash algorithm with brute force computing power.

However, as a means of verifying file integrity it is pretty safe.
At least more safe then .zip which relies on CRC checksums.
I have had the occassion that a corrupted .zip archive still unpacked, with a glitch in the audio as result...
It might be that this error appeared -after- unpacking, while writing the unpacked files to disk, but still WinZip did not see the error...
WinRar has performed better but is less popular, especially when dealing with Mac based clients.

MD5 checksums have saved me on a number of occasions, I use them as much as I can when sending/receiving files (over network as well as optical discs).
I am really glad Sonoris has it implemented natively within the interface.

bests,
Title: Re: DDP fail
Post by: tbridge on March 30, 2011, 01:33:16 pm

I have had the occassion that a corrupted .zip archive still unpacked, with a glitch in the audio as result...

Ouch  :o It seems to me that MD5 is pretty secure, and would catch a corrupt file, whereas you say unZipping might not, so you may as well stick with only MD5? Plus, there is a school of thought that questions the integrity of the audio after Zipping, but this seems to be one paranoia too far!
Title: Re: DDP fail
Post by: tbridge on March 30, 2011, 01:45:12 pm
My client has received a hefty bill for re-packaging from his broker (though, interestingly, not a bill for re-pressing...hmmm...).

Yesterday, I sent off a detailed email to my client, carefully explaining why the factory seems to have been rather lax in their QC and that I shall need to see a full Report from the factory before I accept any liability. He forwarded that email to the broker, asking for comments, and things have been strangely quiet.

I do not intend to be held responsible for this on the say-so of a broker who clearly has no idea what this is all about - but I fear that in the end, I may have to come to some agreement with my client  ::)
Title: Re: DDP fail
Post by: phonon on April 01, 2011, 09:38:08 am
yes indeed, but that also includes checking the PQ, which has not been affected by a whacking great silence in Track One.
Thanks for clarifying that the MD5 you sent does not, in fact, pass the master EDL, as you originally wrote, but that it, rather, passes the DDP image that you dumped from the master EDL and then (attempted to) upload(ed).   I get confused sometimes with RISC (reduced instruction set chats).
 (The DDP image is - again, for clarity - _not_ the EDL project files and folders.)   

The way of catching a plunk of silence that is inadvertently dumped along with the intended EDL (to DDP image), is to export an audio CD of the DDP image and audition/test that CD for good audio and cueing.   I assume that you did that, as well.  So, the image on your hdd that was used to beam the data for glass mastering also does not have the missing audio?  However, during the FTP, the connection apparently choked and dropped almost exactly 60 seconds of audio without corrupting anything else in the image?   The other audio is perfect and the PQ marks are perfect, CD-TEXT, EAN, etc...?   


And I agree with everything else you say, except that MD5 still seems to be the industry norm for us audio engineers, maybe the CIA needs something more robust.

My point about MD5 was that it's apparently possible for 2 different files to be hacked to produce the same hexcode.   If a replicator wanted to get out of admitting that they screwed a pooch (and ruined a premaster), they might be able to hire a hacker to fake a looks-right MD5 from a broken DDP image and then allege that the premastering clerk had uploaded a bad premaster (with MD5 intact, to prove it!). 


In your case, fortunately, the MD5 is not valid for the copy of the DDP image they have on their server.   So, however it was maimed, there was no attempt to conceal tampering - just failure to check the checksum (OR to verify that the sender had checked his sent image against his local copy's checksum).   Either way, the plant proceeded without a green light (unless you downloaded only the MD5 and compared that to your still-good DDP image (on your hdd) and then told them it was "a go"). 



The great, Wiki, says MD5's not recommended for electronic signatures or SSL.    Stuff that's way below the NSA's radar is still too sensitive for MD5 in many i-contexts.   Though, perhaps not our t'ing....


Here's a familiar palindrome in SHA-256:
6a6d5e31ecd2c3b0ea77c5466f18fa354c7d28831122da4e87582f9f8cd6b169

and, in SHA-160:

9330dffd86b93c8cb0c0b96c80eb90341ee0249c

and, now, in plain old' MD5:
763098442c7a9d2ab74587160cd6c1c2

Can you decode, or guess, how it's meant to read?    ???


Andrew
Title: Re: DDP fail
Post by: tbridge on April 01, 2011, 10:17:53 am
Thanks for clarifying that the MD5 you sent does not, in fact, pass the master EDL, as you originally wrote, but that it, rather, passes the DDP image that you dumped from the master EDL and then (attempted to) upload(ed).   I get confused sometimes with RISC (reduced instruction set chats).
 (The DDP image is - again, for clarity - _not_ the EDL project files and folders.)   
You're right,  I created a DDP image from the master EDL, then burnt a disc from that for my client, which did not, of course, have any additional silence in the first track. The MD5 files were created from that DDP image, and failed on the server, meaning that the uploaded file was different from the DDP file on my local hard drive.

There always was a very small chance that I had somehow managed to make a DDP file containing a minute's worth of silence, but then the MD5 checker would pass this, no?
The way of catching a plunk of silence that is inadvertently dumped along with the intended EDL (to DDP image), is to export an audio CD of the DDP image and audition/test that CD for good audio and cueing.   I assume that you did that, as well.
See above...
The other audio is perfect and the PQ marks are perfect, CD-TEXT, EAN, etc...?
Yup...

Your comments about the MD5 being hacked are, presumably, true, but that's getting a little paranoid, I think... a hacker would probably cost the plant more than they would save in re-pressing costs  8)

I have no idea what your last remarks are about  ???
Title: Re: DDP fail
Post by: tbridge on April 01, 2011, 10:28:50 am
Latest developments...

The broker has contacted my client to say that, while checking the MD5 is NOT part of the Replication Plant's normal QC procedure ( ??? :o ), they (presumably) admit that maybe they should have checked it, so are willing to re-press free-of-charge. The broker, however, contends that, as the corrupt file is down to me, they still intend to charge my client for the un-packing/re-packaging of the CDs (not cheap at about 600GBP), which they suggest he passes on to me.

This is an interesting state of affairs: I contend that I should not be held responsible for a file once it leaves my studio, and that, as the MD5 checker fails the file on their server, it is demonstrably NOT the file on my computer. There's a small chance that I uploaded a DDP file with a hole in it, but then the MD5 checker would have PASSED that, surely?

 I would like the broker to demonstrate that their server is not corrupted, as if they are holding me responsible for upload errors, they must surely also be responsible for the integrity of their storage?

Any thoughts before I get back to them again? I'm tempted to take this further (i.e., call my lawyer) as I think my case is pretty watertight, but my client, who has to pay these extra costs to the broker, is happy to spread the damage over several future projects, so maybe I should take it as (yet another) hard lesson.
Title: Re: DDP fail
Post by: phonon on April 01, 2011, 11:30:53 am

...There always was a very small chance that I had somehow managed to make a DDP file containing a minute's worth of silence, but then the MD5 checker would pass this, no? See above...Yup...

You'd have heard a minute's silence on the ref which you auditioned in toto (or which you at least can Load Back)?.  'T'wasn't missing on the ref of the master premaster.   So couldn't be missing in the master premaster.     

Your comments about the MD5 being hacked are, presumably, true, but that's getting a little paranoid, I think... a hacker would probably cost the plant more than they would save in re-pressing costs  8)

...and I thought the hacker's services - before their rising to cell-lebrity(?) - were typically pro bono [if one could call it that]. 

I have no idea what your last remarks are about  ???

A diversion, merely.  It illustrates the extra complexity and curious charm? of SHA over Message-Digest (burp>)..   j/k

Guess'd the palindrome?


A bull was I air eye saw well baaaah..........  (only spelled, correctly, as the palindrome would require.)

Cheers,
     Andrew
Title: Re: DDP fail
Post by: bblackwood on April 01, 2011, 12:06:08 pm
Situations like this are tough.

The few times I've had to deal with this type of situation I've weighed the value of 'winning the fight' vs the value of potentially earning a client for life. Only you know all the details, but sometimes spending a few dollars you aren't required to spend is a good long-term investment...
Title: Re: DDP fail
Post by: bkuijt on April 01, 2011, 02:08:38 pm
Ouch  :o It seems to me that MD5 is pretty secure, and would catch a corrupt file, whereas you say unZipping might not, so you may as well stick with only MD5?

hmm.... it's weighing pro's and con's:
- MD5 is more secure but voluntarily applied.
- .Zip or .rar is maybe a little less robust but you are FORCED to use it to retrieve the files from the archive.

(My statement is pretty heavy but it only happened twice with .zip and once with .rar. And I did not establish at that time if the error was a corrupted file or an error in the disk writing process after unpacking.)

Many less tech-savvy clients are lost when I try to explain MD5 checksums and getting them to install an extra application for this purpose is a nightmare. Especially since there is no real 'one-step' solution for Mac.
(all the ones I see produce text files in strange places, require manual assembly of the checksum file with copy/paste or do not support nested folders.).

With the people I know and trust I rely on MD5 only. But sending out masters to a client or large factory is usally in .rar format with MD5 checksums included for (voluntary) additional safety.

bests,
Title: Re: DDP fail
Post by: bkuijt on April 01, 2011, 02:35:23 pm
I would like the broker to demonstrate that their server is not corrupted, as if they are holding me responsible for upload errors, they must surely also be responsible for the integrity of their storage?

That's hard to prove, it's more likely a communication error between ftp client and ftp server.
One could make a case saying that communication involves two parties.
Also checking the file could have been done on both ends.

 It's tough indeed and I'm sorry you get burned like this.
 It would be interesting to hear what a lawyer will say about the case.
 But I agree with Brad that your willingness to come to a solution might strengthen your position with the client.
 Maybe sharing the cost with the broker is an acceptable proposition?
Title: Re: DDP fail
Post by: Jerry Tubb on April 02, 2011, 03:28:01 am
Quote
I've weighed the value of 'winning the fight' vs the value of potentially earning a client for life.

Works in personal relationships as well,

sometimes winning ~all~ the battles isn't the best strategy.

You don't always have to be "right" to win in the long run.

JT
Title: Re: DDP fail
Post by: Pieter Stenekes on April 05, 2011, 11:27:47 am
Added a verification function to the DDP Creator that optionally reads back all files and test them against the original files with md5. That way you know for sure that the files were uploaded fine. What happens after that is in the hands of the operator...

Also added a resume function on the upload and download. The update will be available soon.
Title: Re: DDP fail
Post by: tbridge on April 05, 2011, 11:58:25 am
Hi Pieter, that all sounds good...  ;D Will the update be an automatic download when it appears, or do we have to re-visit the website occasionally?

yhm
Title: Re: DDP fail
Post by: Pieter Stenekes on April 05, 2011, 12:11:07 pm
it will be announced in the newsletter
Title: Re: DDP fail
Post by: tbridge on April 12, 2011, 11:12:28 am
Update:

After lengthy discussions with the Plant, the broker has now waived all re-pressing costs...
 :) ;)
Title: Re: DDP fail
Post by: bradsarno on May 17, 2011, 08:34:58 pm
Question.

If I've created a DDP file set say via SoundBlade, that exists as a folder of DDP file set components. How do I generate a MD5 Checksum for that folder? Every time I try it seems I need to generate an individual MD5 for each component file within the DDP folder. Should I zip first, and then generate an MD5 for the single zipped file?

Oh, and congrats on having the plant cover the re-pressing!

Thanks,
Brad

Title: Re: DDP fail
Post by: JimK on May 17, 2011, 11:21:05 pm
Question.

If I've created a DDP file set say via SoundBlade, that exists as a folder of DDP file set components. How do I generate a MD5 Checksum for that folder? Every time I try it seems I need to generate an individual MD5 for each component file within the DDP folder. Should I zip first, and then generate an MD5 for the single zipped file?

Oh, and congrats on having the plant cover the re-pressing!

Thanks,
Brad

Hi Brad,

I've been using DDP Creator from Sonoris as of late and it's very convenient that the MD5 Checksum is created from within the application.

I have also created DDP image files from Peak and used Checksum+ from Pescados Software to create the MD5 Checksum. After selecting the folder that contains the DDP components, Checksum+ will open the folder and allow you to select all of the files in the folder to create one MD5 Checksum for all of the files.
Title: Re: DDP fail
Post by: bkuijt on May 18, 2011, 04:27:24 am
Another option is 'MD5' (http://www.eternalstorms.at/md5/index.html) which also allows selection of multiple files within a folder.

It still amazes me that no easier checksum program has been written for mac.
There are plenty of Windows apps that handle folders recursively or however you choose...

The idea would be to include the md5 checksum of the original files inside the zip archive to
be able to verify that the extracted files are identical to their originals.
Title: Re: DDP fail
Post by: hnewman on May 18, 2011, 01:06:41 pm
Apologies if this has already been mentioned, but it's worth knowing that the latest version of DDPEXPORT packaged with Sequoia 11 automatically generates checksum files.

Title: Re: DDP fail
Post by: bradsarno on May 18, 2011, 01:54:33 pm
So if I do a checksum of the grouped files contained within the DDP folder, would I then save the checksum outside of that DDP folder, place all of that within a parent folder and then zip it all into one file. Then the recipient will know to apply the checksum to the group of files within the DDP folder? Seems a bit messy or begging for confusion at the receiving end.

How good is zipping with regards to this kind of data verification? How about zipping the DDP folder, and then creating a checksum for the zipped file?

Brad
Title: Re: DDP fail
Post by: JimK on May 18, 2011, 02:11:43 pm
The Checksum will be saved inside the DDP folder with all of the other component files. You would then just zip the main DDP folder with the Checksum file included inside it.

Zipping has not failed me yet.
Title: Re: DDP fail
Post by: bradsarno on May 18, 2011, 02:37:18 pm
Perfect!   :)

Checksum+ created one MD5 for all files in the DDP folder. Sonoris DDP Player (among other MD5 tools) was able to check that MD5.

I assume there's no issue at the plant when there's an MD5 file sitting in the DDP folder. I assume it ignores it.

Thanks for all the help!

Brad
Title: Re: DDP fail
Post by: JimK on May 18, 2011, 02:53:17 pm
Hopefully they run the MD5 Checksum at the plant!

Happy to hear it worked out for you.
Title: Re: DDP fail
Post by: tbridge on May 18, 2011, 02:54:06 pm
Hey Brad

I would not assume anything! :)

edit: Oh, re-reading your post, I think that's what you're doing  8)
Title: Re: DDP fail
Post by: lowland on May 19, 2011, 03:48:55 am
I assume there's no issue at the plant when there's an MD5 file sitting in the DDP folder. I assume it ignores it.

That's true: SADiE also automatically generates an MD5 if you want it to and puts it in the DDP folder. It's been able to do this for quite a few years, and by now I must have supplied several hundred masters made this way to factories all over the place without problems.