"Path must be an absolute path" when using batch audio process USD export

I’m giving the Audio2Face tool a shot and I’ve run into a unhandled exception when using the “Blendshape Weights USD” button in the “Batch Audio Process” window.

I’ve got my blue guy (male_bs_46) following the grey guy (male) perfectly fine. Also, if I use the “EXPORT AS USD SkelAnimation” button, to just export the current sound file, it seems to work fine. Or, at least the export finishes without throwing an exception.

However, when I use the batch export button, it moves through the first animation frame by frame, and then throws an unhandled exception upon completion of the animation.

log from console follows:

2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] Exception when async '<function Exporter._run_export_batch_audio_blendshape_weights_usd_async at 0x00000225A6F134C8>'
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] 
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] 	Error in 'pxrInternal_v0_20__pxrReserved__::UsdStage::_IsValidPathForCreatingPrim' at line 3258 in file C:\b\w\ca6c508eae419cf8\USD\pxr\usd\usd\stage.cpp : 'Path must be an absolute path: <>'
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] Traceback (most recent call last):
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils]   File "c:\users\brad\appdata\local\ov\pkg\audio2face-2022.1.1\exts\omni.audio2face.common\omni\audio2face\common\scripts\utils.py", line 31, in wrapper
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils]     return await func(*args, **kwargs)
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils]   File "c:\users\brad\appdata\local\ov\pkg\audio2face-2022.1.1\exts\omni.audio2face.exporter\omni\audio2face\exporter\scripts\exporter.py", line 2227, in _run_export_batch_audio_blendshape_weights_usd_async
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils]     skelAnim = stage_out.DefinePrim("/World/anim_{}".format(skelAnim_prim_name), "SkelAnimation")
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] pxr.Tf.ErrorException: 
2022-10-11 17:37:05  [Error] [omni.audio2face.common.scripts.utils] 	Error in 'pxrInternal_v0_20__pxrReserved__::UsdStage::_IsValidPathForCreatingPrim' at line 3258 in file C:\b\w\ca6c508eae419cf8\USD\pxr\usd\usd\stage.cpp : 'Path must be an absolute path: <>'

I took a look at line 2227 in exporter.py and didn’t notice anything particularly out of order. I compared with line 1764 which is the comparable part of the single take export (which does work), hoping to find an obvious discrepancy. Nothing jumped out immediately. But I’m unfamiliar with this code.

I did want to hook up a debugger. But unfortunately, opening the extension in VSCode via the extension manager doesn’t really allow me to set a breakpoint and attach the debugger. That empty ‘<>’ in the exception message coming from cpp is suspect. But I don’t have the source code or the debugger working so… dunno.

Thoughts? Help? Known bug? Seems similar to: Problems in Batch Processing Blendshapes in .USD format - #2 by siyuen

Hi Brad,

Thanks for reporting this, I’ll follow up with the dev team on the latest status on both issues. Meanwhile it would be helpful to have the full log to see the A2F version and spec

Sure. Attached find a fresh log.

I started A2F.
I opened my previous file which already has a set of wav takes with keyframes, a grey head and a blue head.
I hit play to make sure both heads are reacting to the already loaded take.
I hit the batch export button.
It reached 100% and then threw the exception in the console.
I hit “cancel” to close the frozen window.
I closed A2F.

kit_20221011_145607.log (639.4 KB)

Hi @brad_f,
I found this is due to the .wav file name.

  1. Can you remove all hyphen “-” in the audio file name and probably replace it with underbar “_”?
  2. If you have any dot “.” in your audio file name (except the file extension like .wav). Please remove or replace it with “_”.

Then the batch processing should work.
We will fix this in the future release. Thanks for letting us know the issue!

1 Like

Thanks for the workaround. I’ll give it a shot.

You say you’ll fix in a future release. Which is good.

I’ll just point out the source of the “-” because I think it may be relevant to A2F as a production tool.

These audio files are generated from Davinci Resolve ( DaVinci Resolve 18 | Blackmagic Design

Basically, I did an ADR (automated dialog replacement) session in the fairlight page to get my performances. I collected my raw clips on a timeline in the edit page, to assemble a pseudo “reel” for export to wav, and as source media for editing and assembly. I used the “deliver” page to dump them to WAV, which regularizes the filenames (the ADR tools give horrendous names and doing an additional re-composition and delivery of a well named ‘reel’ feels like a good solution here)

The addition of the “-” (dash) is actually automatic. For my part, my “reel” is named with “_” (underscores) because I personally try to avoid the use of “-” (dash). However, Resolve uses a “-” dash for separating their suffix (padded incremental integer) and a different delimiter cannot be chosen in the default workflow. This is a Resolve shortcoming. But Resolve and fairlight are de-facto industry standard tools. To be useful in production, one must conform to their restrictions.

For broader context: The move from “reel” (physical, numbered reel) based workflows to “file” based workflows in post-production has created a lot of confusion and conundrums over the years. And unfortunately, the actual full filename is often the only real way to track and re-conform media through an extended production pipeline. Despite desires to organize better with meta-data that flows through the process.

All of that preposition is to say: The solution here really needs to try and preserve the “-” (dash) through the A2F pipeline. When I get my filename for my USD or JSON or whatever file-based output, on a 1:1 basis for the original WAV file, it really needs to go the extra mile to reconstruct the original filename with the “-” (dash) even if internally, it had to substitute “_” (underscore). The same would be true of an extra “.” (dot). Not because I’m lazy, but because I don’t get to control the filenames of the WAV files I need to process to the degree that I would like. And the added complication of having to conform mangled USD animation filenames to original wav filenames (after export, in third party software), is a complication the A2F pipeline should avoid creating.

Further, any name mangling that does go on to satisfy internal naming restrictions is going to need to be surfaced to a utility function for use by pipeline developers, so we can easily take a raw filename (tracked name) and deterministically re-mangle it to an internal name ourselves, to work with the internal representation. In other words: if name mangling is the solution, please don’t burry it inside the monster batch export function. Please separate it out so we (pipeline devs) can use it too. Because we’ll probably need to generate it from raw filenames too, to interpret A2F internal data.

Side note: ProTools is more standard than Fairlight. But Resolve and Fairlight are important enough for production to make sure to consider them when thinking about how something like A2F will be used in broader production pipelines.

Hi @brad_f , thanks for the very helpful information! We recognize that the restriction in the file name can be painful for many pipeline work.

We will release a hotfix version very soon, and the fix for this function will be included in the hotfix version. You can use dash or dot or any available character in the audio file name. :)