Disabling avidemux restriction: "Some tracks are used multiple times"

Started by Alex K, January 06, 2020, 03:29:36 PM

Previous topic - Next topic

Alex K

Happy New Year, everyone! Joined just now, prompted by this issue:

Sometimes, on a video with a fancy flavor of DTS audio encoding or the like, it makes sense to add an audio track version mixed down to a more widely supported audio encoding across devices and players, such as DD or MP3 or PCM - while also preserving the high quality original track.

Yet, when I try this on the current/recent version of Avidemux, I get an info pop-up that prevents that:
Error
Some tracks are used multiple times

Firstly, I feel that this should be a warning not an error (and as such a warning should be informational - not terminating a given workflow). Secondly, I wish there were an option in settings to disable this particular check.

What is the latest avidemux version where this error message is not implemented in a way that prevents multiple versions of the same source track?

Many thanks!
Alex
P.S. I realize I can export and re-import but it's multiple extra steps, plus all the sync settings etc.

eumagga0x2a

There is no backend support for multiple use of an audio track, the check in the GUI simply conveys the truth.

Alex K

Thank you for looking into this!

Quote from: eumagga0x2a on January 06, 2020, 07:15:51 PM
There is no backend support for multiple use of an audio track

Hold on, if I can make an MP3 or PCM track out of a DTS track in avidemux today, why can't those tracks be added to the output BESIDE the original DTS track, as opposed to replacing it?

eumagga0x2a

To get audio packets for an audio track stored in a container like mpegts, mkv or mp4, we use functions provided by class ADM_audioAccess. Objects of this class are allocated internally by respective demuxer one per track and we can obtain the pointer by calling getAudioStream() (s. this method implemented in the Mp4 demuxer).

In order to supply more than one single consumer with audio packets, we need as many accesses as consumers, i.e. we must be able to allocate access later upon request. I don't know, maybe it can even work :)