Giving the 8.5 demo a trial, loving everything about it BUT think I’ve found a bug which has put a dampener on my festive spirit.
For releases with multiple final formats (with multiple bit/sample rates) I build the montage at the sample rate of the masters then SRC/dither as appropriate when rendering the individual tracks or making a DDPi. The album in question followed that pattern.
The mixes for this album came in at 24/48. As described above, I mastered the tracks in the Audio File view at that bit/sample rate then sequenced them all in the montage view at the same bit/sample rate. The publisher wanted PQ sheets for the vinyl and CD versions, so I made “CD Reports” with Raw Text. At this point I sent them off. I’ve done it this way with WL7 for years and had no problem. However, I still had the text files open and then noticed that timings were slightly off… I knew the album was around 49 mins but the CD Report was showing up a total time of 53 and the all track timings were longer than shown on the timeline. I made a Rich Text file. The track timings on this tallied with the time line and the total duration. I opened up all the 16/44.1 and 24/48 renders I’d made from the original montage and their timings tallied with the rich text file. I imported the DDPi I made for the CD and the timeline and track timings tallied with the rich text file. I burned a CD and imported that into WL and played in VLC - guess what? The track times and total time matched the Rich Text file and not the Raw Text.
At this point I opened a montage done for one of the sides of vinyl. It’s in 24/48 with track markers added for the PQ sheet. I made a Raw Text CD Report… the timings were wrong. I made a Rich Text CD Report… the timings were right. As the DDPi for the CD would “natively” be in 16/44.1 I imported that and made a Rich Text and Raw Text file…both were correct.
Is this something to do with the original 48k sample rate for this montage? Could whatever is feeding data the raw text simply be doing the maths incorrectly?
Aside from the embarrassment of me having to go to the publishers and pressing plant (the files and PQ sheets for the vinyl release have already been uploaded to their servers) with new PQ sheets it’s a pretty weird problem. Has anyone else had this?
If this is true, I may have a TON of incorrect reports sent off to lacquer cutters as I usually do the main digital master montage at 44.1k and then recreate at higher sample rates for vinyl and those that want high sample rate masters for various online distro.
I’ll take a look tomorrow at some montages and reports tomorrow and report back.
Using what was given out as the demo version - the About window says it’s 8.5.0. It was downloaded on 4th December 2014. If the Steinberg website is giving out demos that aren’t showing its products in all their glory it’s probably worth raising with them.
I love Wavelab, have been using it since v4, but will be skipping v8. Like many people here I rely on it for my income and this incident has shaken my confidence in the brand. Looking forward to seeing what v9 has to offer.
While we’re on v9, really hoping that exporting a montage as a DDPi in bit/sample rates other than 16/44.1 makes an appearance. Won’t be a moment too soon with the currently high amount of differing delivery requirements.
Actually, while this thread is still near the top of the front page, I’ve experienced some anomalies that I’ve never had before. FWIW I noticed them in the same montages as the previously reported CD Reports bugs but only noticed them today. Are the following known errors or could they be linked in any way to the non 44.1k CD Reports bug?
Fades being “reset”. I put in a couple of fades and saved with the montage. They seemingly disappeared after I reopened a few days later.
Clip length altered. Again, I edited the length of a couple of clips and they appeared to change after I reopened a few days later. I checked these against a (correct) PQ sheet from a few days before and they were definitely different.
Both the above points affected the same clips. Is it possible that the montage just “forgot”, or failed to write the necessary part of the save file, or maybe even reverted back to a previous state? I’m assuming that if the montage save file “corrupted” in some way it would become unopenable?
This project has caused me so much bother and made me look like an idiot… Not hard usually but I’m really hitting my head against a brick wall this time
I’ve brought this up in the past. Even if it can’t be a true DDP at 24-bit/high sample rate, some kind of DDP-like package to deliver a reliable master to clients in various formats would be amazing.
Right now I deliver a 16-bit/44.1k DDP with HOFA DDP Player to clients for approval because the DDP and DDP Player is very “idiot proof” and the files can’t be changed as far as sound quality and spacing between songs within the player. The HOFA DDP Player makes it easy for clients to export WAV files or burn a CD that contains CD-Text and no accidental changes.
Most clients are not as tech savvy as engineers and struggle to manage and understand raw WAV and mp3 files, even with special instructions. Since using the HOFA DDP Player I’ve had very little “user errors” from clients when listing to masters for approval.
When the DDP is approved, then I deliver other formats which is usually 24-bit and higher sample rate if the project is higher than 44.1k.
Between making the new montage at a higher sample rate, and managing all the formats, it can be a lot of extra work. I can recreate simple montages at a higher sample rates fairly easy, but recreating complex montages at a higher sample rate referencing files that are the same length but a higher true sample rate can be hard.
If there was a way to make a custom DDP-like player to send to clients that only played the files in their exact order and didn’t allow editing of sounds and spacing between songs that would be great. The ability to keep the files at 24-bit/native sample rate would also be ideal with the option for the client to export the files at various rates like 16-bit/44.1k, mp3, AAC (with full metadata tagged) and other misc. formats using a high quality sample rate converter like iZotope SRC that would be a bonus. Maybe some sort of special limiter-like process would need to occur to make sure that there are no overs when converting from 96k to 44.1k for example since any conversions in this scenario would be after the traditional final limiter in the Wavelab montage.
I know this is a lot to ask but right now the file delivery process can be a little messy because there are more variables than there was in the 90’s for example when it was just CD master, and vinyl (maybe cassette). Now we have CD master, 16-bit/44.1k WAV for online distribution, 24-bit/high sample rate for Bandcamp, SoundCloud, and Mastered for iTunes, and vinyl pre-masters.
I’m glad to see conversation about this very real issue: we have few options for coherent program delivery above 44.1/16, yet we’re all delivering higher res parts for all kinds of new targets. This makes mastering fun and exciting today, and represents the future market for apps like WL.
Allow me to specify targets I’ve delivered in the past 30 days:
A/B vinyl LP, EP and single sides at 96/24, with “PQ” track listing
A/B cassette (!!?!?!) sides at 44.1/16
192/24, 96/24, and 88.1/24 MfiT ingest track files
320K MP3 and 256K AAC LP d/l companion file set
The track listing and flow are essential for LPs and Eps at all resolutions. For individual track/file deliveries, the approving artist should be able to reconstruct this flow with 0sec gaps easily. Most don’t know that iTunes allows this, and live with default settings or crossfades, so that’s a problem.
This is an interesting era for mastering, and WL could take better advantage of it by providing a cueable DDP-like image that can be previewed minus any changes or effects. The more reliable and bulletproof, the better.
