Effects that change duration of a track

Effects that change duration of a track

[James Rowe]

Hi,

  So, you’re laying in bed listening to a podcast with an effect
that modifies playback length, such as sox’s ``tempo -s 1.9``.  How do
people deal with dtas-console displaying the “wrong” duration¹?  Or, is
there a correct way to manage effects that modify track times?

Thanks,

James

1. Laying in bed looking at dtas-console in termux on a phone screen is
   hard enough without having to do mental arithmetic ;)

Re: Effects that change duration of a track

[Eric Wong]

James Rowe <jnrowe@gmail.com> wrote:
> Hi,
> 
>   So, you’re laying in bed listening to a podcast with an effect
> that modifies playback length, such as sox’s ``tempo -s 1.9``.  How do
> people deal with dtas-console displaying the “wrong” duration¹?  Or, is
> there a correct way to manage effects that modify track times?

It's a known problem.  dtas-player_effects(7) manpage does warn
against effects which modify track times.

dtas would have to know about which sox effects which could
alter track time, and there's also LADSPA plugins, too...
Things get complicated really fast.

Another solution would be similar to what we do for trim/volume
ReplayGain and expose a parameter/effect which dtas itself will
use to inject "tempo" into the effects chain.  It covers the
majority of cases like yours, I think; but doesn't cover effects
like "splice" or "vad"

> Thanks,
> 
> James
> 
> 1. Laying in bed looking at dtas-console in termux on a phone screen is
>    hard enough without having to do mental arithmetic ;)

Heh.  I just never cared about track times too much when just
listening to what I'm listening to.

Re: Effects that change duration of a track

[James Rowe]

* Eric Wong (e@80x24.org) wrote:
> [Great explanation]

  Okay, thanks for the detailed explanation.  I hadn’t considered the
issues that deeply.

  FWIW, I’ve opted for a cheap hack that Works For Me™ with the simple
modifiers like tempo.  Simply calculating the current time as the
``track_length * (current_offset/current_expect)``, and displaying it
with a dzen2¹ widget.

> Another solution would be similar to what we do for trim/volume
> ReplayGain and expose a parameter/effect which dtas itself will
> use to inject "tempo" into the effects chain.  It covers the
> majority of cases like yours, I think; but doesn't cover effects
> like "splice" or "vad"

  I’ll note that it doesn’t concern me enough to write the patch myself,
so I’m clearly not that stressed by it.

Thanks,

James

1. https://github.com/robm/dzen