Fix NS_E_NO_MBR_WITH_TIMECODE (0XC00D1BDA) in Windows Media Encoder

What tripped you up

I know seeing error 0XC00D1BDA mid-encode is maddening — especially when you're on a deadline and the file simply won't finish. This one's been around since Windows Media Encoder 9 Series, and it still catches people off guard.

The fix: turn off script commands

The fastest way out is to disable script commands in your encoding session. Here's the step-by-step:

1. Open Windows Media Encoder (start > all programs > Windows Media > Windows Media Encoder).
2. Load the session that's throwing the error, or create a new one.
3. In the Session Properties window, click the Script tab.
4. Uncheck Enable script commands.
5. Click Apply and OK.
6. Try encoding again.

That's it — the error should disappear. If you absolutely need script commands (like captions or URL flipping), you're stuck with single-bitrate output.

Why this works

Windows Media Encoder's multi-bitrate (MBR) feature creates multiple streams — say, 300 kbps and 700 kbps — so the player can switch based on bandwidth. The problem is that script commands rely on a single, shared timecode track. When you're encoding multiple bitrates, the encoder can't figure out how to stamp those commands consistently across all streams. So it throws NS_E_NO_MBR_WITH_TIMECODE and stops dead. Disabling script commands removes that conflict entirely.

Less common variations of the same issue

Script commands hidden in a profile

Sometimes you didn't explicitly enable script commands — they're baked into the encoding profile you're using. If you're loading a custom .prx file or a Windows Media profile, check the script tab anyway. I've seen people waste hours re-installing the encoder when it was just a profile that had script commands turned on by default.

Third-party plug-ins injecting commands

If you're using a tool like Expression Encoder 4 (which superseded WME), the same error can pop up when a plug-in — like a closed-captioning injector — adds script commands automatically. In Expression Encoder, check the Script section under Encoding Options and make sure it's empty.

Command-line encoding with WMCMD

If you're running a batch job via wmcmd.vbs, you might see this error when the script includes a /script parameter alongside /mbr. The fix is to remove the /script switch or change /mbr to a single-bitrate output. For example, instead of:

wmcmd.vbs -input input.wmv -output output.wmv -script myScript.js -mbr 300,700

use:

wmcmd.vbs -input input.wmv -output output.wmv -script myScript.js

and accept single-bitrate at the default quality.

Prevention for next time

If you regularly encode multi-bitrate streams, keep these rules handy:

• Never mix script commands with MBR. The encoder simply won't do it. If you need scripted interactivity, you must encode a single bitrate and let the player handle bandwidth adaptation on its own (or use adaptive streaming protocols like HLS or DASH instead).
• Audit your encoding profiles. Before loading a profile, open it in Notepad and search for ScriptCommand. If it's there, remove those lines or switch to a clean profile. A clean profile for WME looks like this in its XML (partial):

<Profile>
  <StreamPrioritization>...</StreamPrioritization>
  <ScriptCommand Enabled="0" />
  ...
</Profile>

• Update your tools. WME 9 was last updated in 2006. If you're running it on Windows 10 or 11, you might hit other issues too. Consider moving to a modern encoder like FFmpeg (free) or HandBrake — neither has this script/MBR conflict. With FFmpeg, you'd use -b:v:0 and -b:v:1 for multi-bitrate without any script command restrictions.

One last thing: if you're encoding for Silverlight or old Windows Media Player scenarios, keep a single-bitrate fallback profile ready for any file that needs timed script commands. That way you don't scramble for a fix when the error shows up.