The Importance of the Memory Buffer in an Optical Disc Duplication Controller

buffer-vs-buffer.jpg buffer-vs-oldman.jpg
There are many critical components and functions on a controller that will determine the overall performance of that device. Yet there’s one element that is easy to source and rarely differentiates in capability or performance, the memory buffer. The function of the memory buffer is to temporarily hold data while it is being moved from an input device to an output device. For example, the buffer will temporarily hold data from the master source in the reader which will be copied onto blank media in the writer drives. The necessity for a memory buffer is due to the fact that often the writer drives can write faster than the reader drive can read the data to them. This is especially true with the larger bandwidth formats like Blu-ray. Additionally, in most situations, 1 or more of the writer drives will be noticeably faster than others. That means that the faster drive(s) would have to slow down or stop in order for the slower writer drive(s) to catch up due to the fact that all the data is being written simultaneously across all drives. Irregular copy speeds amongst writer drives in a single duplicator can play havoc on ones production time and efforts.

buffer-vs-buffer.jpg

Most writer drives are built with the PC market in mind, meaning typically using 1 drive to copy 1 disc at a time. Using those drives in a duplication environment, where it could have as many as 15 drives connected making 15 copies at a time, there is far more instances where the drive burning speeds are not truly in sync. The buffer is intended to keep enough data stored so that the fastest and the slowest writers drives will not need to stop (referred to as “Burn Proof”) or error out because they cannot get the data transferred quick enough.

An important element of the memory buffer is that it must use either DDR or DDR2 memory chips. Only DDR or DDR2 memory chips are fast enough to grab large bandwidth data from the reader and relay it simultaneously to multiple writer drives in order to copy that data onto recordable media. Those using the traditional SDRAM memory chips will not be able to provide the speed necessary and will ultimately lead to Buffer Under-run or errors in the copied discs.

buffer-vs-oldman.jpg

Another critical element for the memory buffer is its size. The larger the buffer the more data it can hold and the more tolerance it will have when the writer drives differ in their duplication speed or they are unable to keep pace with the reader itself. That means less burn proofing, so less potential for failed discs, and higher quality copies. This is especially true for the larger formats like Blu-ray where there is a great deal more data to transfer.

It has been brought to our attention that some controller manufacturers, in a cost cutting maneuver, are not using DDR or DDR2 memory and have downgraded their controllers to only 32MB of memory buffer. This will of course reduce the overall cost of the controller, but they are dramatically sacrificing quality and reliability as a trade off.

Vinpower Digital is not willing to sacrifice the integrity and quality of our products to save a little money. Ultimately the cost savings would end up costing us much more in the loss of confidence and eventually sales from our customers. That’s why we use a minimum 128MB memory buffer with DDR2 memory chips to ensure the highest quality and reliability. So when you’re looking for a duplication controller or even a complete duplicator, make sure you know exactly what you’re getting and not just what the price is. There is a difference, so it’s important to be educated so that you can make the right decision. In doing so, you’ll ultimately save money buying a better quality system which doesn’t require as much maintenance or support so that you can pay attention to more important things.

No Comments yet »

RSS feed for comments on this post.

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>