DDP?

[fl]

To the powers that be at Merging:

I find myself debating about buying the DDP option for my Pyramix setup. On the one hand, it certainly would be a handy way to get files and sequencing for CD production to the replicator in a way that is secure.

On the other hand, it's over $1000 CDN. Ow! When you see that Wave Editor (for the Mac) has the capacity to make DDPs and the whole program costs $80 - it makes me ask, why is the Pyramix version so expensive? A Licensing issue? Exotic bells and whistles?

Any hope that in the future the price might come down? Or perhaps even be included in the basic program?

[avi]

Frank,
I don't think it's licensing; the DDP license (from DCA) is free / no-cost.
It does seem odd that DDP, which some would see as being essential for mastering a CD for manufacture, is excluded from some PMX versions, but I guess the feature-set lines have to be drawn somewhere. It's a shame it's so expensive though, it's so much as to make the other options ones to consider & use. If DDP for Pyramix was half the current price it would still be much more more expensive than WaveEditor but I know a few folk who would then buy it since the extra is worth it for ease of use /workflow & peace of mind. At it's current almost 11x the cost of Wave Editor (£54 vs £600 I think), that's a large saving. I don't believe the Wave Editor DDP function has the same "Performer Field" bug that PMX is suffering from currently either. . .

[fl]

At its current almost 11x the cost of Wave Editor (£54 vs £600 I think), that's a large saving. I don't believe the Wave Editor DDP function has the same "Performer Field" bug that PMX is suffering from currently either. . . :?

According to the Audiofile-Engineering (makers of Wave Editor) forum, there may or may not be a bug in its DDP implementation - like just about everything else about that program, it's rather unclear. One of the most cumbersome user interfaces I've come across in a long time, but hey, I managed to pick it up on sale over Christmas for about $60 CDN, as opposed the the $1100 price tag for the Pyramix DDP licence - for that kind of difference, I'll plug away and learn the program. And you say there's a bug in the Pyramix version? Interesting...

[avi]

It doesn't seem to be a major one, but see Ricardo's last message here:

viewtopic.php?f=4&t=4184

Apologies if this has been fixed in a recent update; I'm sticking with v5 here until the little issues with v6 we read about on here have been ironed out so I'm not fully aware of all the updates etc.

[Graemme]

DDP "performer field" bug is fixed in v6.1, which is in early beta.

The DDP license is not the issue - Merging use the Gear Software 'engine' for CD and DDP writing. This *does* cost money (and apparently, quite a bit). I do agree that the a la carte DDP key for DiscWrite is much too expensive. It does make more sense when included in the mastering bundle, which is really the only way to buy it.

I like Wave-Editor for it's ability to read DDPs from DiscWrite, et al. They (audiofile-engineering.com) now have a new programme for playback and burning of DDP images to CD-R, called 'Backline' . This will be great for Mac-based clients (most of mine are) who would be put off by WaveEditor's clunky interface.

Best,

Graemme

[tas]

While we are at it and since I am about to finish off my first album mastering session, I would appreciate it if someone can explain the advantages of using DDP over Redbook. All I could find is that its an alternative, but not much more.
thanks

[fl]

While we are at it and since I am about to finish off my first album mastering session, I would appreciate it if someone can explain the advantages of using DDP over Redbook. All I could find is that its an alternative, but not much more.
thanks

Apples and oranges here...

Red Book refers to the standard that was established by Philips and Sony back in the day when they introduced the CD. The "Red" book refers to the standards for manufactured Audio CDs (technically, the CD-Rs that people use to make Audio CDs on computers would fall under the "Orange" book standard - why the colours? They sent the secretary out at lunch to buy a bunch of three ring binders to hold the paper descriptions of the various standards they developed, and she got a different colour for each standard). Among the Red Book standards are the error correction protocols established for playback in commercial CD players - cyclic redundancy, error concealment, Reed-Solomon cross-interleaved error check code, etc. - which will possibly correct, conceal, or mute errors arising from the CD media itself, when it is played back in a CD player that is in compliance with the Red Book standard (which Sony and Philips licence to the various equipment manufacturers). There is some redundancy of the audio data, but not as much as when you save audio as a computer file (Wave, AIFF, SD2, PMF - heck, even MP3). Computer files are much more robust in that there is more actual data redundancy, which you can see when you find that you can put 740 or more MB of data on an Audio CD, but can only store 640 MB of data on the same kind of disk when you make a data CD. The restricted amount is because of the greater amount of data redundancy when you burn a data disk. If you send your material as data to a Mastering and/or Replicating house, you stand a much better chance that your audio will arrive in the safest possible manner, and thus, wind up on the duplicated CDs as close to the original as possible, if not actually identical.

When you send an Audio disk burned on your computer, they have to "extract" it at the other end to get your material, so there are a few places where your data could get corrupted: your computer's burner, faulty CD-R media, the CD reader at the other end, dust everywhere - and the error concealment inherent in the Audio CD standard means that errors can creep into your data that nobody is aware of. Worst case, there could be a great, honkin' drop out in the middle of your audio data, that gets pressed into the zillion copies you're having made - not the best option, I'm sure you'll agree.

Sending data files as WAV or AIFF files is a better option, since you take advantage of the computer file's more robust structure to preserve your data. However, here the replication or mastering house still has to take your files and sequence them in the order you want, placing the pauses where you want them and for how long, as well as entering all the CD text information along with the ISRC code for each cut on the disk, the UPC code for the disk, and all the other information that accompanies the audio material on a modern manufactured CD. They'll usually bill you for the time it takes as part of their set-up charge.

The DDP allows you to send your audio material as a data file - so it's much more resistant to media induced errors. It also allows you the benefit of doing all the sequencing and placement of pauses to your exact specifications (the PQ codes), and has a provision for you to enter the various codes used to identify the disk (UPC) and the individual cuts (ISRC), along with the nifty CD-text stuff like the disk title, the performer(s), and title and composer information for each cut. Because a DDP package can include a checksum, there is some hope that if anything happens to your data on the media you provide, it will be caught before it gets pressed into a zillion copies, allowing you to replace the material with a copy that is hopefully error-free.

My initial post in this thread came about because I'm in a similar position to you - I have a client who will be going to press CDs in a month or two, and I want the data to get to the finished product in a form that has to pass through the fewest number of processes after it leaves my hands. I'll probably use the DDP making resources of Wave Editor, or this new Backline that Graemme mentioned - or maybe there might be some enterprising Pyramix owner with a Mastering Pack out there, perhaps someone on the west coast, who'd be willing to take a .pmi file and turn it into a DDP, insuring that all the "t"s are crossed and "i"s dotted...

[Graemme]

Hi Frank,

You really just put that line in at the end to see if I read that far into your post...

I'm up North right now, but send me an email after the 18th and I'll get you my FTP coordinates (in other words, I'd be happy to do that for you).

What I now do for DDPi projects is to make the listening copy 'final' CD-r from the DDPi as an extra precaution. Also for electronic delivery, after uploading the DDPi, I download it and do a bit compare with my source. This procedure proved it's worth when, one time, a seemingly successful transfer was somehow corrupted.

WaveEditor imports DDPi's made with DiscWrite, so you can burn a CD-r and verify that it sounds like you intended it to, as well as checking for CD-Text, etc.

Would you please check something for me? In the project menu in Pyramix, under 'Import', is there an entry for 'DDP import' on your system? I can't remember if that function is available without a DDP key.

Best,

Graemme

[fl]

Would you please check something for me? In the project menu in Pyramix, under 'Import', is there an entry for 'DDP import' on your system? I can't remember if that function is available without a DDP key.

In my Native Music Pack, all the various Import options are present, but most of them, when selected, inform me that I need a key (like for the OMF and/or AAF Import functions). Happily, the DDP Import function is both present and functional, and works much the same as the CD Import function in terms of the available options and the file handling. All the disk IDs show up in the CD tab, along with their CD-text entries - very slick. I tested this with a DDP folder created by Wave Editor, which Pyramix imported without a hitch. I noticed that there are two options for getting the audio data imported: the radio button "Import All Contents" imports the audio as a single contiguous file, whereas "Import Selected Tracks" coupled with the "Select All" button imports the various cuts as seperate files. In both cases, the CD markers are placed correctly.

Can you answer a question for me? In the CD tab, where all the CD-text information gets entered, there is a column labeled "Copy", which I assume is for Copy Protection. However, it's not clear in the manual whether a "Yes" or a "No" means that Copy Prevention is in effect. From the looks of it, the heading "Copy" would infer that a Yes in that column would mean, "Yes, copying is allowed.", but could just as easily mean, "Yes, Copy Protection is in effect."

In my view, it really would be worthwhile to change the English Language resources for the program so that the header is a more complete "Copy Protection", and the column entries were "On" or "Off", and I have made a post to the Suggestions forum to that effect.

[tas]

Frank thanks very much for the info, its more than I could ask for and extremely useful. I guess I can't use Pyramix to create DDP either, I don't have waveditor either but I know its relatively cheap. Please let me know if you manage to use it succesfuly.

As for going down the Redbook/audio route, I assume everyone else got an email from Merging with a link to a CD Image player as well. I haven't looked at it yet but I assume thats our best option to quality check a premaster CD-R burned with PMX before sending it out to the plant?

edit: Answering my own question: Probably not as it can do nothing about burning errors right? So is sticking it to a normal player a valid testing procedure?

Thanks

tas

[fl]

Frank thanks very much for the info, its more than I could ask for and extremely useful. I guess I can't use Pyramix to create DDP either, I don't have waveditor either but I know its relatively cheap. Please let me know if you manage to use it succesfuly.

I did manage to generate a useful DDP package with Wave Editor, which I was able to load back into Pyramix to check for accuracy, and all seemed well. It even included the fake ISRC and UPC codes I made up for making this test DDP (I haven't gotten the official ones yet for the project I'm working on, and I'm hoping that those will come from the replicator when it's time. There are some good resources on the net about ISRC codes that a Google search can bring up, if you're curious.)

As for going down the Redbook/audio route, I assume everyone else got an email from Merging with a link to a CD Image player as well.

Hmm, no - I guess I'll have to ask Merging directly. You'd think with all the time I'm in here whinin'...

I haven't looked at it yet but I assume thats our best option to quality check a premaster CD-R burned with PMX before sending it out to the plant?
edit: Answering my own question: Probably not as it can do nothing about burning errors right? So is sticking it to a normal player a valid testing procedure?

Here's where you can start chasing your tail. I'm guessing the CD image player software is simply designed to take a .pmi file and play it like the CD player inside Pyramix - without having to launch Pyramix itself, so that won't tell you about any errors on your CD-R media. Playing it in a CD player will take advantage of the CD player's own error correction/concealment capabilities, and will usually result in you not hearing any data errors, unless there is something truly gross going on with your CD-R media. This is the point where you start to ask yourself, "Well, if I can't hear any problems when I play it, surely it must be good enough?" Well, only you can answer that for yourself and your clients, but there are some programs out there that can examine a disk for dropouts and data inconsistencies - I had one a couple of years ago that ran on Mac OS 9, but I don't have one now. I'm sure there are other people on the list who could suggest some things. Could be handy....

Or...

You could just avoid the whole issue of whether your Audio CD-R is good enough and either send Data files (.wav or .aif) to your mastering/replicating place, along with a detailed description of how you'd like it all to appear on the finished product, or you could cough up the $79 USD for Wave Editor, spend a couple of days to learn how to navigate the user interface, and then be able to create a DDP complete with a checksum file that you can either send to your replicator electronically via FTP, or that you can burn onto a CD-R or DVD-R (along with detailed documentation, just in case) to send by mail or courier. And if you're worried about THAT, you can do what Graemme suggests, and import your burned DDP into Pyramix, flip the polarity of the audio tracks, and play it at the same time as your original 16 bit files to see if there is anything but silence, which would indicate an error. If that's all good, then you should be good to go. I have heard of people who actually take their hard drive to the mastering/replicating house, or sending by courier if it's not local - I guess it comes down to how much you wish to worry about this stuff. The main thing is to examine the process you want to use, and identify all the points where data corruption could occur, and do your best to minimize that possibility. Beyond that, well, there's always going to each customer's house, setting up the band and playing for them, which is perhaps not quite as convenient...

[tas]

Very useful, thanks. The data way seems much more logical. I 've been having problems with Discwrite anyway. Just today a number of blanks got destroyed whlle trying to burn an image and I only managed a succcesful write when I went in and set the BurnProof parameter to True. So it looks like the CD-R software or hardware is having a hard time.

On that image player, I now see that its only a beta but I 'd be happy to send you the link or the zipfile if you want.

[tas]

Beyond that, well, there's always going to each customer's house, setting up the band and playing for them, which is perhaps not quite as convenient...

Thats not such a bad idea at all actually. Who cares about CDs these days anyways?

[fl]

Very useful, thanks. The data way seems much more logical. I 've been having problems with Discwrite anyway. Just today a number of blanks got destroyed whlle trying to burn an image and I only managed a succcesful write when I went in and set the BurnProof parameter to True. So it looks like the CD-R software or hardware is having a hard time.

Yes, it's a little touchy - I have two Macs (Bootcamped) and Diskwrite will only write CDs if I choose the fastest burn speed available - 24x. Over on the Mac OS side, I have a full range of speeds available when I burn stuff from Wave Editor or Toast.

What you can do if you are going to go with the data files method, is set up your disk in the CD tab in Pyramix, just as you would if you were going to make a .pmi file. Include all your CD-Text stuff, and all the codes. Pyramix has a function that allows you to print out a detailed paper form describing the sequencing and timing of all the audio and codes for the disk - it will even let you choose from a selection of presentation styles, and you can go so far as to replace the Merging logo with your own for print out. Supply one of these with your data and most every replication house in the world will be able to deal with things for you.

On that image player, I now see that its only a beta but I 'd be happy to send you the link or the zipfile if you want.

Great - thank's very much. I'll PM you here with my email address.

[Perfect Record]

Much to my surprise, in the mastering workshop at the last AES, Bernie Grundman said that he felt they were getting the best results from submitting CDR production masters.

There wasn't really much explanation or follow up on that point.

Our practice here when making DDP's is to load them back in and make a CDR for and end to end check audition. First thing I do before doing a full audition is skip through and check all the track starts. Nothing worse than getting 70 minutes into a check audition only to find out that the last start mark is in the wrong place.