Loading a (possibly corrupt) AIF file puts ATL in an endless loop

[seankearney]

The problem

I have an AIF file (that is seemingly corrupt), but ATL is "locking up" when we encounter it. The call to var track = new Track(path); will sit for hours before ultimately having to be killed; it never returns in my testing.

Environment

• Found in 4.33, but also reproducible with caec6e6
• Windows 10

Details

I believe that the issue is around position 928534 in the audio file. In file AIFF.cs read( goes and calls into seekNextChunkHeader and the returned headers start to return a negative length. I believe that this effectively puts the read( method in an endless loop.

Code To Reproduce Issue

Problematic File - DFC08D25-8F8E-4324-8425-30D6D9452626.zip

string path = // path to the attached file.
Track t1 = new Track(path);

[seankearney]

I've put up a repo with the reproduction.

• .net8
• ATL 5.12

I've confirmed this is an issue on two machines.

• Win 10, i7, 32 GB ram
• MacBook Air M1, macOS 12.6.3, 16 GB

[Zeugma440]

Thanks for your feedback and for providing all the details.

Right now I'm on vacation without access to my dev environment. I'll take care of your issue as soon as I'm back home (i.e. beginning of january).

Thanks for your understanding~

[seankearney]

Sure thing! Thanks.

Next week I'll have someone on my team be able to look as well; perhaps they'll be able to provide more insight beyond my ability to reproduce it.

[Zeugma440]

Got it! That file has custom chunks whose IDs are written with lowercase letters (e.g. basc, trns) whereas ATL expected chunk IDs to be written in uppercase, as all standard IDs are.

The fix will be included in next release, hopefully very soon.

[Zeugma440]

Fix is available in today's v5.13. Please close the issue if it works for you~

[seankearney]

Thanks for the quick turn around! I can confirm that my issue with this file is gone with 5.13 .