@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?
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.
1 Like
agreed, you can also send him over the file, whatever works best!
1 Like
@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?
Please say a lot more about how you’ve determined this.
I placed a breakpoint at this line in ‘ARDOUR_UI::new_session_from_aaf()’ :-
std::shared_ptr region = create_region (source_regions, aafAudioClip, *oneClipSources, sessionStart, samplerate_r);
I then modified the AAF import so it’d only import the 2 problematic clips and once the breakpoint got reached, I traced into the code until I saw where the value 56244787200 got generated - which was in a call to boost::multiprecision::convert_to()
That seems pretty clear but also seems pretty damning … to say that we’ve found an error in a widely used multiprecision arithmetic library is quite something (not unprecedented, of course)
Well I guess another possibility might be rounding. ‘PBD::muldiv_round() is getting called, so maybe it’s rounding something up where it’d be better to round it down?
In 'ardour_ui_aaf.cc’ the function ‘create_region()’ calculates clipLen to be 9565440 which later equates to 56244787200 / 5880. Whereas the correct value should’ve been 9565082 which equates to 56242682160 / 5880. And according to my calculator, 9565440 == 9565082 x 1.000037428 which could easily be a rounding issue.
Still confused though… 
[Edit…[ Interestingly, 48000 * 1.000037428 and then converted to int would give 48001, so maybe this is a rounding error somewhere? I’ve no idea how we’d find it though.