|EYM AUDIO WATERMARK PERFORMANCE INFORMATION|
The two most critical performance criteria when evaluating a watermarking approach are:
In addition to these two core concerns, there are a couple of more practical issues:
Performing rigorous listening tests was beyond the limited scope of this shareware's development cycle. In the absence of any sophisticated psychoacoustic model I am fairly confident that a reasonably trained listener should be able to detect perceptual differences between an original file and its encoded version in a high quality A/B/X listening environment. In other words, don't expect the EyM Audio Watermark to be truly transparent.
Yet the more relevant question you should ask is whether its audio quality is good enough for your application. If you target consumer grade listening environments, where people might be satisfied with the audio quality of an MP3-compressed recording, then I doubt anyone would complain about any audible artifacts introduced by this watermarking process. Ultimately though, only you can be the judge of that and I encourage you to freely experiment with various configurations of this shareware to find a compromise between transparency and robustness that may best fit your needs.
Lossy audio compression:
The primary persistence goal for this shareware was that the watermarks should survive most popular kinds of lossy compression such as MP3. This was confirmed through early tests of the system.
It was further quantified using a set of 100 files (summing up to about 7 hours of mostly pop music) which were watermarked with an 8-byte payload (plus time stamp) at the default gain 1.0, compressed to MP3 at 128 kbps using a popular media player and decompressed back to 44.1 kHz WAVE files using the same media player. The decoder had no trouble recovering the 8-byte payload from these "post compression" audio files.
D/A - A/D, resampling and acoustic coupling:
The arbitrary binary payload you provide is turned into a data packet that includes some synchronization, error checking and the optional 12-bit time stamp information. Because of this fixed overhead the effective data rate at which you mark your audio is a function of your payload size.
For instance, conveying a payload of only 1 byte (8 bits) with an optional time stamp will create a data packet that gets repeated at a 1.7 seconds interval throughout the audio stream (i.e. the equivalent of a 4.7 bps data rate). On the other hand, conveying a payload of 8 bytes (64 bits) without time stamp will create a data packet that gets repeated at a 3.4 seconds interval throughout the audio stream (i.e. the equivalent of a 18.8 bps data rate).
But thinking of the data payload efficiency in terms of its encoding data rate can be misleading. Indeed the audio stream can be thought of as a tempestuous and intermittent data channel. Not all embedded watermarks will go through, even if the audio material is not degraded. This is why the same data gets repeated throughout the audio stream, allowing the decoder to use an expected redundancy in order to retrieve that payload despite the intermittence of the data channel. From this perspective it is easier to understand why shorter packets have a better chance to "get through" while providing a higher amount of redundancy that further helps their recovery.
And hence the following rule of thumb: you should always carefully consider the nature of your application in order to identify the smallest watermark payload that will fit your need. As a hint, don't necessarily think of that payload as explicit information but rather as a simple identifier that can be subsequently linked to specific information. A 4-byte (32 bits) identifier can be used to distinguish between over 4 billion objects.
CPUs have gotten so fast that the most noticeable bottleneck for this kind of process can be disk access for the WAVE files I/O. This is certainly noticeable on the 3 GHz Pentium 4 laptop I'm using, which has a 7200 rpm disk.