EW-DP wonky sampling frequency?

[Jason Nicholas]

I've just picked up the Sennheiser EW-DP ENG kit with both the plug on transmitter and the body pack for working on a little one man band short documentary I'm doing. One odd quirk on the SKP 32bit recording (and 24 as well) is that I'm getting files that are at an odd sampling rate of 46.875? Is this some kind of clocking flaw in my unit or does it not record at a standard sampling frequency? It's going to be quite annoying to have to batch convert everything if so.

[Jason Nicholas]

Followed up with Sennheiser; this is apparently normal operation: 

 

Quote

The EW-DP SKP is built on the Evolution Wireless Digital (EW-D) platform, whose native internal audio sample rate is 46,875 Hz. This is the underlying rate used throughout the EW-D architecture to maintain consistent audio transmission performance across the platform.
You are correct that this differs from the 48 kHz format referenced in the published specifications. The 48 kHz figure reflects industry-standard workflow compatibility, particularly for broadcast, video production, and post-production environments. Internally recording and storing files at an exact 48,000 Hz would require either additional processing after recording or dedicated sample-rate conversion hardware, both of which would add complexity, power consumption, and processing overhead to the device.
 
There is also a technical rationale behind the chosen rate. The 46,875 Hz sample rate is tied to the EW-D platform's internal clock architecture and RF transmission design. This approach supports the system's ultra-low latency performance, signal stability, and the wide dynamic range that the platform is designed to deliver.
With respect to your video production workflow, while the source files are recorded at the platform's native rate, our testing has shown that most professional DAWs handle this transparently when importing media into a 48 kHz project. In cases where playback hardware does not support 46,875 Hz directly, as you've experienced, applying a sample-rate conversion to 48 kHz remains the most practical workflow. Because the source rate is fixed and stable, the conversion process will not introduce timing drift against properly recorded 48 kHz camera audio once conformed.

 

Which is a little bit frustrating; not the end of the world as this is the backup recording. Regardless, it's an extra step in post for my use case. I did a SRC from an interview I recorded yesterday. 35min piece and it all syncs up just fine. That said, the audio from the on camera record from the receiver (the digital UHF transmission) vs the on-board 32 bit recording was almost indistinguishable. I was using a Schoeps CMC6/MK41 and, for what it is, it sounds quite good. I'm sure there are circumstances where the 32bit might come in to save the day but for just a sit down interview in a controlled environment, the wireless setup was much better than the previous Sennheiser G series analogue setups I'd used in these same situations. 

[borjam]

I wonder, a software bug registering the wrong metadata?

 

 % bc
48000*1000/1024
46875

 

That is a silly software confusion representing 48000 samples per second into "computer style K's, ie, powers of 1024, instead of the Physics k's, powers of 1000".

Funny!

 

Elaborating a bit more: it's a miscalculation and I guess audio is sampled at 48000 samples/second. Probably there was some confusion between units in the internal product development, or just someone used 1024 as a factor instead of 1000 out of familiarity. Silly but a planet probe crashed because of a unit system mismatch in the past  

 

[Bouke]

"48000*1000/1024"
NIce find 🙂

For 'batch converting', there 'should' be no need.
The wrong value will be in no more than 1 or two places, and fixing would be changing a handfull of bytes only, that can be done in-place and will be no more than a few milliseconds of work.

(I can spit out an app that does this in less than an hour, meaning 45 minutes of making the interface, 5 minutes of coding and 10 minutes for Apple notarizing stuff.)

 

 

 

 

[Jason Nicholas]

I will dig a bit deeper and have a look at the actual embedded WAV metadata header to see what’s up. It does seem like a quite odd design choice when the whole industry is based on 48kHz. Again, it’s a quick fix but it’s a bit of a faff having to do an extra step in post; but I suppose anything right now with 32 bit files does require a little extra work anyway. I don’t think, the way the thing is set up and designed, that it’s really meant to be an everyday working file. It’s rather a ‘save my bacon’ kind of recorder. It’s easy enough though to just set up a batch convert in Wavelab to take all the files, SRC to 48kHz, normalise and then output a new file for editing.

[borjam]

Try without converting, just rewrite the sample rate metadata. 

[Bouke]

13 hours ago, borjam said:

Try without converting, just rewrite the sample rate metadata.

Why not write only the 4 bits in the header? (And, if there is iXML / bext, rem out the SR if rewriting that is too hard.)

It's just 4 bits, with a hex editor it can be done manually without any hassle to test. (That cannot fail, pretty sure of that.)

 

Or, send me a sample and I'll alter them as a test. 

[borjam]

Yes, that’s what I mean. I recall the very old Soundhack program made it easy?

[Bouke]

13 hours ago, borjam said:

Yes, that’s what I mean. I recall the very old Soundhack program made it easy?

 

My bad, it was indeed very clear. (I misread it for rewrite samples, aka a re-write without conversion.)

I don't know SoundHack, but same as for  WaveAgent, I think the 32 bits will be no problem, but if the files are Rf64 it will fail.
(WaveAgent won't play the files, but will be able to alter the metadata)



 

[Jason Nicholas]

So, just to triple confirm on this. Sennheiser are correct in stating the odd sampling frequency. If I go into the WAV header and manually change the frequency to 48kHz, the resulting file readily opens as a 48kHz file but on a 30 some minute interview drifts out by nearly a minute. If I, instead, run a sample rate conversation of that original file from 46.875kHz to 48kHz, the file syncs up perfectly. So, again, strange but a navigable extra step. Considering that a 32bit to video timeline workflow for me would involve both a bitrate conversion to 24 and some kind of normalisation regardless, the extra step of an SRC in a batch conversion script in Wavelab isn't really much of a burden. It's just something to be aware of. 

[borjam]

Ok, that is what I was wondering. So they really used the wrong sample rate.

 

I would contact Sennheiser, I think it’s a bug to use a non standard sample rate in a professional product intended for sound for video.

 

 

[Jason Nicholas]

I've already contacted Sennheiser and they said this is normal operation (see response above). Was just confirming it.

[Bouke]

2 hours ago, borjam said:

So they really used the wrong sample rate.

For the AD converter, yes.
But, if the files sync correctly, the TC is set at 48K, or it would not sync properly after changing the SR, right?
So in this case,  the TC reader / generator has a mismatch.
Enough reason to return it as faulty.

 

[Jason Nicholas]

Just to be clear, according to Sennheiser, the recorder is operating normally and recording a 32bit 46.875kHz file. There is no timecode so there is nothing to reconcile there. The sync is either done manually or by an automated match with the scratch track from camera. It does seem like a strange design, but it's really not a problem in the end. I just asked the question to see if I did happen to have a faulty unit but I'm satisfied with the resolution as, for this application with this setup, I'll be using the audio recorded in camera from the receiver almost all the time as long as I take care to properly set levels the old fashioned way. 

[Bouke]

5 minutes ago, Jason Nicholas said:

There is no timecode so there is nothing to reconcile there

Sorry, my bad, I thought so since you wrote:

 

8 hours ago, Jason Nicholas said:

the file syncs up perfectly.