8 bits missing when recording from AES/EBU

I am presently troublehooting a weird problem I have with Wavelab since version 7. I have done some new tests to nail it down.
(See below post the details of my configuration )
When I record a 24 bit signal though my configuration , the resulting soundfile is officially 24 bit, sound quality is fine BUT : when reading the file and watching the bitmeter only the top 16 bits light up, the last 8 bits have been truncated.
I have tried sequentially in many different orders to record (Win XP) in wavelab 6, 7 and 8
The result is always the same, everything ok, full 24 bits in the file recorded with Wavelab 6. Allways 8 bits missing in wavelab 7 in 24-48k, most of the time the same in 44,1kHz. I thought that maybe the driver malfunctioned but how is it then that I record ok in W6 ?

I installed a clean Windows 7 to use wavelab 8.5, and it is the same problem. Again the driver is showing no signs of malfunction apart from this truncating thing

I have to say that once I tried changing settings from temporary file recording to specific and back, changing resolutions etc, and things started working again, but the next day it started again truncating the last 8 bits, and I have never been able to reproduce this.

ASIO TEST : If I use the ASIO driver, the problem disappears, I get all 24 bits in my files. But this makes my life a living hell as I keep switching in the course of my work from 441 to 48 and back. This forces me to manually switch the clock reference to avoid glitches or files that don’t play in the right speed. It makes my workflow very insecure.
OK, so before I throw the whole system and invest in a new Soundcard System I want to make sure that this is not some configuration bug or hidden option somewhere. Any idea as to a test procedure I could use to further narrow down this problem is welcome !
Thanks for any light on the subject
Mark Haliday


Hardware :
PC with XP (Wavelab 6 - 8) and W7 (Wavelab 8.5)
Sound Card : RME DIGI96/8 PAD (http://www.rme-audio.de/old/english/digi96/digi96pa.htm) : Although this PCI card it is technically legacy hardware, the card and the drivers (32 bit only) are very stable and trustworthy, as is usually the case with RME
Wavelab I/O config : directly through MME-WDM drivers, NOT Asio as this links input and output clocks, which in my case makes my life impossible since I keep switching very often between 44,1 and 48k in input and output.
Record Configuration : Through the AES/EBU input of the DIGI96/8 PAD, the digital output of my HD 96 I/O form Pro Tools HD rig in real time. Sampling frequency can be 44,1 or 48kHz, almost never 96k
The soundcard when in XLR (aes) locks its input to the incoming stream, and has a safety that prompts a error message in Wavelab if I try to record in 441k when the input in 48k. Very convenient and SAFE
Record Settings : temporary file, 24 bit 44,1k or 24 bit 48k

RME PAD96/8 Soundcard specifications
Supported sample frequencies: 32 kHz, 44.1 kHz, 48 kHz, 64 kHz, 88.2 kHz, 96 kHz
All settings changeable in realtime, all output options even in playback mode
Separate record- and playback circuits; complete master mode
Enhanced Full Duplex: Different sample rates at input and output possible
Mixed Mode: ADAT® in - SPDIF out and vice versa at full synchronization
AutoSync: Automatic and intelligent master/slave clock control
Unsurpassed Bitclock PLL (audio synchronization) in ADAT® mode
Optional Word Clock Module (WCM) provides word clock input and output
TMS (Track Marker Support): Supports CD/DAT start-IDs and the read out of CD subcode
Comes with DIGICheck: the ultimate measurement, analysis and test tool
Unique status windows for record and playback, showing mode and sample rate
Zero Latency Monitoring: Hardware bypass per track, controlled by Punch-in/out
AutoSelect searches automatically for an input with valid signal
Combined Channel Interleave/Multi Device driver compatible to almost all recording programs
Complete interrupt-sharing
Windows driver with Pentium® optimization (quad times memory transfer)
High bus transfer rate (up to 130 MByte/s)
Digital inputs and outputs ground-free transformer coupled
Super low jitter design: < 1 ns in PLL mode (44.1 kHz, optical in)
32 bit memory transfer and 128 kB fast SRAM guarantee very low system loadAnalog input +4 dBu/-10 dBV configurable
Superior analog 24 bit/96 kHz input. Dynamic range 109 dBA
Flexible superior analog 24 bit/96 kHz monitor output. Dynamic range 112 dBA
Low impedance output (75 ohm) ready for headphones, stepless output level through software faders
Speaker Protection minimizes noise during power on/off
Analog output routable to ADAT® tracks
Digital I/O: optical (TOSLINK), coaxial (phono), internal (CD-ROM/Sync-I/O). Optional breakout cable (not included in standard version) provides AES XLR connection.
Formats SPDIF-AES/EBU (Consumer, Professional), ADAT®

I did a check and find the same as you (almost). That is, the MME driver truncates the samples from 24 to 16 bit, when recording. But this happens also in WaveLab 6. When I analyse the samples, I can see the samples “arrive” truncated. This is not the WaveLab’s action.

This being said, there is not much sense recording in 24 bit with MME, because the samples collected by the driver goes through windows internal’s mixer, which means “there are not pure” but may get gain change.

If you want the true direct original samples collected by your audio card, you have to use ASIO.

Thanks for the feedback !

Update : - Using the RME Digicheck app to test the input stream confirms that under Windows 7 the input is good 24 bit, locked properly to clock etc. - I have installed The latest Wavelab 6 under Windows 7 and I record in full 24 bit

I am a bit surprised by your statement : >>>“This being said, there is not much sense recording in 24 bit with MME, because the samples collected by the driver goes through windows internal’s mixer, which means “there are not pure” but may get gain change.”<<<.
Because I don’t go through the microsoft mapper, all windows stuff is routed to the internal realtek soundcard of my PC, I also deactivate system sounds completely. The mixer isn’t even connected to the RME drivers.
And the 24 bit MME drivers are high quality. Steinberg Asio is great but I see absolutly no technical reason to consider that MME drivers should be bad
I have been working like this ever since I bought the Sek’d 96k card and later the DIGI PAD 96/8 (the same product really as the Sek’D but win2k/NT/Xp compatible)
ASIO driver is an absolute pain for me. I don’t need sophisticated mixing options. I just want output an input to live freely, and seeing that this has worked for me for 10 years with technical exactness I don’t see why this should change !
I am perfectly ready to have two soundcards on my system if necessary !
Thanks for any ideas on this


I have a similar setup. I have a RME 9636/52 PCI card which I use to capture via AES from an external Lavry converter.
It is a hassle if you are locked to an external source and wanting to work in a different sample rate in Wavelab for playback or editing. Plus not to mention since the RME has additional ADAT i/o (which I never use) the number of outputs change because of smux at 88/96k giving me less outputs. So, at 48k my main outputs are D36… at 96k I have to manually change them (I save a preset) to output A9 @_@
That being said… I still prefer this hassle over using MME or any lesser soundcard. The RME with ASIO is rock solid and to my subjective hearing,it’s crystal clear (I haven’t done bit perfect testing).
A simple solution to having to change the samplerate temporarily is to just shut off the Lavry and the RME goes to internal sync. When I’m ready to capture again, just turn it on and goes back to external…
Since you’re using Protools HD maybe turning off the interface is not convenient, maybe a XLR patchbay or a Zsys will be handy…

Another possibility I use a lot when working at another SR than my 96k soundcard rate, is put a resampler in the Post slot of the master section and switch it on or off as needed. That way it’s always left out of the rendering process.

This is an interesting option. I’ve used it on the master section with the fear of exporting at the wrong SR.
Never thought of the Post slot… Could this work while capturing?

Asio is fine with me but I see no technical reason why well designed windows drivers as are RME’s excellent ones should work less well than ASIO. I know we are in ASIO country here :slight_smile:, and I agree that it is a very stable and solid way to enable bussing and mixing of inputs and outputs of a soundcard for DAW purposes, but at the cost of operational restrictions that have in my case absolutly no justification.
I just hope something will be found to avoid this problem !