Opened 15 months ago

Closed 15 months ago

Last modified 15 months ago

#7243 closed defect (invalid)

Supplying redudant arguments changes actual ouput response

Reported by: joblow Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


By adding these command line values for reading a 16-bit 44100hz wav file causes the data to be subtle altered.

-af atempo=44100 -ar 1

It seems that the resampler is not perfectly accurate(could be edge noise) and it does not check to see if it doesn't even have to resample. Or it could be the rate.

The code should not process the data for rate change if the rate is 1. If the sample rate is the same as the source it should not try to resample.

Change History (8)

comment:1 Changed 15 months ago by richardpl

Your ffmpeg command is invalid.

comment:2 Changed 15 months ago by joblow

I, obviously, meant -af atempo=1 -ar 44100. (it is obvious because if the values were truly reverse then there would be no subtle alteration)

comment:3 Changed 15 months ago by richardpl

  • Resolution set to invalid
  • Status changed from new to closed

The atempo filter is designed that way.
The -ar command insert aresample filter, and it alone give exact same audio output.

comment:4 Changed 15 months ago by cehoyos

  • Component changed from ffmpeg to undetermined

comment:5 Changed 15 months ago by joblow

So, what you are saying that when one supply a rate change of 1, which is no rate change at all, that it is ok for ffmpeg to alter the data? This is non sense! I guess someone just wants to get out of fixing the bug!

comment:6 Changed 15 months ago by richardpl

It is not bug, filter is designed that way, also filter is pretty obsolete, but others dev oposed new/better filter addition for doing same operation.

comment:7 Changed 15 months ago by joblow

There is absolutely no way you can make sense when you say it is designed that way... if it were it was designed wrong and you cannot justify it being wrong by saying it was right.

A range change by a factor of 1 is NO CHANGE! That is what 1x means, it means no change! Now, if it means no change then why the hell is it changing the data?!?!

To stay that it was designed to do that is ignorant. The code to fix it is very simple:

if (rate == 1) return data; else return changeRate(rate, data);

What you are doing is starting from your conclusion that because the filter behaves that way that it was designed right then concluding that this it behaves correctly. That is ignorant logic.

comment:8 Changed 15 months ago by richardpl

Filter is obsolete, use rubberband.

Note: See TracTickets for help on using tickets.