Thanks for trying. The deveoper was a member here called @agfline so hopefully he might join us here.
Sorry for the OT question but in your screenshot that is a very unique window decoration theme, I’m curious what it is and what DE/WM you’re using? I geek out on that kind of stuff…
@GMaq - I’m running Windows 10 here but I don’t like the ‘blocky’ look of Win10 so I use something called WindowBlinds which makes it a bit easier on the eyes!
@calimerox - can you remember where the non-working AAF came from? e.g. Avid / ProTools / Nuendo or whatever?
they come from premiere, and I imported them before with no issues (well some fades changed etc…) into davinci resolve
Phew, that’s quite a relief! I don’t know about Adrien (@agfline) but I took a look through my various test files and I don’t have any AAFs here which came from Premiere. So it’s likely we’ve just never had the chance to test them…
I’m wondering if you’ve somewhere where you could upload the faulty AAF so we could try it? Maybe in a zip file if that’d make it easier?
Hi @John_E, Hi @calimerox
Thanks for reporting this issue.
Some lightweight test files are available in the libaaf repos and all those starting with PR_* are from Premiere.
If @calimerox had no issue importing into Resolve and not into Ardour, that’s obviously an issue with libaaf.
Just like John said, we’d need an AAF file to work on. If your file is too heavy for you to send, could you reproduce the “faulty” AAF file with Premiere, in a smaller file ?
1 Like
Hi Adrien - I spent this morning importing your PR_* AAF’s here and although they all produced an Ardour session, none of the sessions contained any clips on the timeline.
[Edit…] Apologies… for your 2 x 'Internal’ AAF’s the audio was present. It was just a tiny tone blip (after the timeline’s End marker - so it didn’t get played and I only just saw it)
There was no audio for the non-embedded samples though. And another oddity was that all 3 sessions got created with a sample rate of 22050Hz - even though your WAVs and AIFFs are either 48KHz or 44.1 - so I’m guessing there must be some weirdness going on within the Premiere exports.
@John_E If it would help, when I have some time, I will import some of these into Cubase 12 or 13 and see what the results are.
AAF files in the libaaf repos are first intended for testing with the library (using aaftool / test.py), to check all the specific file structures produced by various editing software. Thus, those files might not always be relevant in actual import tests.
Regarding sample rate, since AAF doesn’t hold any metadata for project sample rate, libaaf checks all essence files, then select the sample rate with the highest occurrence. Not sure if this is the best way to go… but that’s how it works right now. And FWIW, most editing software (Avid MC, ProTools, Resolve, even LogicPro) will export all essences with the same unique sample rate. I’ve only seen Premiere pro exporting different sample rates so far…
You can, but I usually test libaaf against each AAF test file before I do any update into Ardour. However if you have time, it might be interesting to export a few AAF files from Cubase, since I had no chance to test it yet 
There a a LOT of things to test per editing software, so let me know if you have time and I’ll list those for you.
I am uncertain of how long this will take to do.
How about a list of things to test, ranked by priority, and I will see what I can get to as time permits ? Or any other method of breaking into smaller chunks of work.
Hi Adrien… after a few more tests this morning it looks like your non-embedded Premiere AAFs might have an audio clip missing from your repo (the missing clip would be called stereo-identif.wav )
Do you have it at your end? And if so, is it small enough to be emailed it to me?
1 Like
Good idea John, I’m going to write a guide for testing any editing software’s AAF with libaaf, so anyone can contribute to it it in the future.
Sure, I’m sending it to you.
2 Likes
Thanks Adrien - after adding stereo-identif.wav I can now import your non-embedded sessions. The bad news is that when loaded in Ardour, they won’t replay any audio or move the meters etc. The good news (hopefully!) is that it’ll most likely be an Ardour problem so I’ve started a different thread.
2 Likes
@calimerox - I went off track a bit but it’d be helpful to know if you can get us a non-working Premiere session for testing… thx.
1 Like
yes! i cannot share that file publicly , but I can mail you a download link?
Thanks calimerox - Harrison’s Mixbus site allows me to send you a private message so I’ll send you my email address. Thanks, John
1 Like
@agfline - I’ve downloaded the AAF session from @calimerox and I see what’s causing the problem. The session has a subfolder called AAF-Medien which contains 4 x wav files and those ones all get imported. But for some reason, the other audio files are distributed among 35 sub-folders. If I copy all the wav files into the same folder as the AAF file it imports okay. I’m quite busy today but if you can let calimerox (or me) know that you won’t share it publicly, we can email you a download link. Hopefully shouldn’t be difficult to fix 
[Edit…] Hmmm - it’s not as simple as I thought… after closing the session, it won’t re-open. It gives me this error message:-
I’ve managed to fix the problem though I don’t understand what’s causing it. Basically there are 2 x tracks called Audio 3_L and Audio 3_R - with both tracks having a single clip running the full length of the session. After closing the session then re-opening, Ardour and Mixbus detect each timeline clip as being longer than the available audio. Unfortunately, Premiere is using different units from Ardour / Mixbus. Premiere reports the available audio length as 0x91f39a whereas we report it as a56242682160@a4611686018427387903
My guess would be that for some clips, there might be an error happening in the conversion.
Maybe related to this?
