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.
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?
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.
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.
@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.
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
@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?
That’s quite interesting, Peter… there was a similar problem recently in Mixbus where it was failing to display waveforms. That also turned out to be because it was trying to read data from beyond the end of peakfiles (i.e. the files on disk):-
Hi @calimerox, could you please send me your AAF file link so I can download it and dig into that import problem ?
I understand it contains copyrighted material. I already worked on many copyrighted AAF files to make libaaf. Trust me, your file wont end up on the internet
Hi Agfline - if @calimerox agrees, I could send you his email address so you’ll both be in contact.
agreed, you can also send him over the file, whatever works best!
@paul / @x42, back on Oct 15 I posted a screenshot showing an error message I see when loading some session files. @peder posted a link to say it’s probably the same issue reported here.. Did it ever get fixed? I’m still seeing it today when trying to import an AAF session here.
No. That still happens on occasion.
I suspect the issue can be produced by either using Music Time a session time-domain or when time-stretching regions. At least sessions that I have fixed for users always had either of those. - But I have not been able find a reliable recipe to reproduce or explain the issue.
Thanks Robin - in this particular case I’ve two timeline clips whose start time / length (initially) show as start=“a0” length=“a56244787200@a0”. And if the session gets saved with those values it’ll then give me the above error dialog when trying to re-open it.
But if I truncate the clip end times very slightly before saving and then wind each timeline clip out to its full length again, the saved values become start=“a0” length=“a56242682160@a0” which allows the session to be re-opened without any issues. Does shed any light on the problem?
I guess the corresponding source file’s length is a56242682160
(3’19"28)?
Yes Robin, that’s pretty close. Two clips are showing the problem here (albeit that they’re L&R sides of a stereo clip). In the actual AAF file, ‘length’ for them both (in samples) is showing as 0x91f39a, which is just a tiny bit less than your estimate.
And in the working .ardour session (i.e. the one I tweaked) ‘Regions’, shows the two relevant regions as having length=“a56242682160@a4611686018427387903” - and ‘Playlists’ shows both regions with a (seemingly matching) length of “a56242682160@a0”
Yet in the original import (before I tweaked anything) the entries under ‘Regions’ are identical - but under ‘Playlists’ both regions show a slightly larger value of:- length=“a56244787200@a0”. This one produces the above error dialog if I try to open it.
The error itself occurs at this line in SessionPlaylists::load():-
error << _(“Session: cannot create Playlist from XML description.”) << endmsg;
and a corrsponding description gets printed to stdout:-
Region TRAILERMUSIK EPI MORE THAN GENES.wav_L has length a56244787200@a0 which is longer than its (first?) source’s length of a56242682160
Unfortunately, even with all that info I can’t tell why (or where) the length would’ve got miscalculated as being a56244787200
Maybe there needs to be a check somewhere that when a playlist region’s length is being calculated, it can’t be greater than the corresponding source region?
I’ve tracked this calculation down to 'boost::multiprecision::convert_to()’ which can be found in ‘boost/multiprecision/number.hpp’ and which we call from ‘Temporal::samples_to_superclock()’ (via ‘PBD::muldiv_round()’). It’s a complicated route but I guess it might be libboost that’s getting the calculation wrong…
Either way - isn’t there somewhere where we could add a check to ensure that the calculated length isn’t greater then the length available in the relevant source region?