@Vondry thanks for reporting this issue. Good to hear the new AAC capability is actually being used.

The duration of ADTS/AAC is a bit nasty to implement (even Foobar2000 did not calculate the duration of my sample files), so I skipped it deliberately, I was curious if someone would point it out.

If I implement it, the duration calculation will be expensive (will take a while to calculate), each and every ADTS frame has to be parsed. Therefor I will map the option to retrieve the duration to the duration flag.

Hi, thanks for such a quick reply.

Let's assume small sized file, which has between 5-10Mb. I have no idea how much time it may take, but if it takes less than a second, it is OK in my case. Since I parse all files before the actual app starts and then i really need duration property to be present.

Have a nice day. :)

but if it takes less than a second, it is OK in my case

I don't think so, probably a few seconds, maybe even more then 10 seconds...

Sorry, these MPEG/AFTS frames which require byte-hunting are terrible inefficient to parse in JavaScript. AAC is using very small frames which makes it even worse.

This performance issue should be definitively highlighted in docs with some related topic, that is for sure.

My app relies on the duration. So if no duration is present, i can not properly visualize progress of current track, so it makes aac more likely unusuable format. I would welcome duration property to be present anyway.

Because this issue is open since a long time I will give an update.
To address this issue, to get the duration out of the ADTS file, I need to improve the MPEG/ADTS parser. Parsing ADTS files, I still experience loosing sync somewhere half way the file.

So it's a lot of work, for a file format which is not very common. Once addressed it will be limited success (it will be slow) at most. Therefor it is not high on my priority list. Since there are not to many other issues, I may do fix it one day.