.
Yes this is bad, because it can be very difficult to track or it can eventually stay fully hided. Human earing can be terribly inefficient in tracking mix problems. I know a couple of those mix problems, that did stay hided during mixing sessions, and that did target the manufactured CDs… But that can be detected by everyone when carefully listening.
Then hided do not exclude that the mix has been altered. I did report a record bug a couple weeks ago, affecting the mix quality, that nobody seems to care of.
This attitude is not right. At least the developers should jumps on such reports, even if users are not terribly worried about it. I feel that bugs that can deteriorate mix quality silently should be corrected as soon as possible. To respect the user and listener basis, but to keep a good corporate identity too and preserve the commercial success of the software in the future.
Software projects that have a good communication between users, testers and developers, can develop very fast and give a very strong code basis with a very low bug count. Nuendo did enhance here in the last two years but still need some more enhancements, hopefully next versions will focus even more on reliability, testing and bug corrections, eventually reducing the amount of new functions.
Anyway this mean that this kind of bug can degrade a mix, and eventually nobody will ear it at least before Disc or Film marketing.
This is why it’s extremely important to have a very serious test suite, an internal tester team, an external tester team that really work with the software, so that 99.9 % of the remaining bugs are tracked.
But even more important is to have a very serious and strong programming, well designed and extremely well documented, so that years after years, when important lead programmers are leaving the team, new programmers can jump on the program, fully understand it, and modify it without disaster.
I remember discussing about that aspect with an SSL engineer, explaining that there were some protections in the software code of their mixing desks to allow detection of an eventual automation data corruption.
This is very important specially for hardware firmwares and drivers that are not often updated, and that sometimes needs an update many years after initial release for compatibility with a new piece of software. When this is not done like this, updating is sometimes impossible (Steinberg TimeBase, no 64 bits drivers, probably partly for this reason…).
Last, in recording studios, in the old days of mixing on large analog consoles with many external effects, null tests were frequents, during a total recall session, to check for the total recall precision.
The mix is recorded on two tracks for that purpose at the end of the session, so that this material can be used for comparison during the next total recall session.
Software is less reliable than hardware because of its complexity inducing a difficulty for programmers to manage intellectually all the aspects of the problems that can be triggered.
So it’s a safe measure to record the mix from time to time, for later null comparison.
.
