FFAStrans forum

Hi,
I transfer MXF with inserted 2 mono audio streams, or extrernal stereo WAV, to broadcast server ingest.

The inserted audio is extracted to tmp WAV, normalized with ffmpeg (-af "loudnorm=I=-23:LRA=6:TP=-9:linear=0") and then merged with "Custom AviSynth script" and "XDCAM-HD" processors to MXF V+A1A2.
Sometimes "XDCAM-HD" encoder stops processing with error "Validate: FFAudioSource: The index does not match the source file."

What do i do wrong?

I found my mistake.
Two upper branches are not in sync. Encoding with "XDCAM-HD" starts before ffmpeg finished.

Hehe isnt it always like this? You work on some problem up to a point where you report it to support and at the moment where you report it, you find the solution?
Anyway, good to hear from you Vladimir, i enjoyed seeing the way you work with functions What does that do?

Hehe isnt it always like this?

When OS was Windows 7 it was stable. Now i need to reconstruct a lot. Found many bugs in old workflows. Look ashamed.
is my way to get "Filename.Ext" from "LongLongPath\Filename.ext"? contained in the variable %s_ext_wav%.
Looks strange, but it works.

Vladimir wrote: ↑Wed Oct 20, 2021 2:59 pm Found many bugs in old workflows. Look ashamed.

Well if there was no history we would always look like noobs, forever. We need to look at history to be able to make it better today (thats kind of an infinite lop)...

Vladimir wrote: ↑Wed Oct 20, 2021 2:59 pm is my way to get "Filename.Ext" from "LongLongPath\Filename.ext"? contained in the variable %s_ext_wav%.
Looks strange, but it works.

Since FFAStrans 1.0 or such, we have the regext function which would make your function combination a lot shorter: Also, FFAStrans already has the values you are looking for, but it only has it for the current "s_source". So, for easy access to name, ext, folders and such, you can just temporalily change the mighty s_source variable to the filename you want to parse like that:
By just setting s_source to your calculated filename, you can access all the juicy inbuilt variables like %s_original_name% and such.
All you have to do at the end is to re-set s_source to the actual source file you want to work with, e.g. %s_pickup_file% is the filename that was originally submitted - in order to make the next processor working with the originally submitted file instead of %s_wav_ext%

Thanks a lot emcodem.
I will spend more time learning "What's new in version ..."

Sometimes it is not easy to deal with passing data through variables. There just isn't enough time.

Sorry, but "change_s_source_temporalily" method can't work. The s_source variable is very stubborn.

I send: то the WF in attached "External_Path-Name-Extention.json"
and have the result:

\\synology.local\InWork\PISMA_IZ_PROVINTSII\Kostomuksha\Kostomuksha.mxf

but not

\\SomeOtherServer.local\a_resource\SomeOtherDir_987654\SomeOtherFileName.ext

as expected.
What could be wrong?

Hehe, I don't think the s_source variable is stubborn. It works exactly the way it should.
You're doing this:

%s_original_path%\%s_original_name%.%s_original_ext% -> %s_submitted_file1% -> %s_temp_var_str% -> %s_success%

So the outcome will naturally be your input file: \\synology.local\InWork\PISMA_IZ_PROVINTSII\Kostomuksha\Kostomuksha.mxf because:

%s_original_path% = \\synology.local\InWork\PISMA_IZ_PROVINTSII\Kostomuksha
%s_original_name% = Kostomuksha
%s_original_ext% = mxf

The %s_source% variable can change a lot throughout a job but the %s_original...% will always stay the same; only populated at the very start from the initial %s_source% variable before any nodes are executing.

Hope this helps.

-steinar

Ah damnit, my bad... i just assumed that the "name" variables change with s_source because the "media property" variables do so.
Really sorry for bringing you on the wrong path here Vladimir