Unfortunately I dont know any tool that guarantees such characteristic. I have performed some simple sample size transformations with sox. In those cases, some extra samples were added as reasoned (?) in the sox manual "Accuracy"-section. I have never seen extra samples added at the beginning of the output. I think that adding in the beginning is not good practice as the meaningfull parts of input and output signals are not in sync anymore. I dont know if some time domain to frequency domain compression algorithms like mp3 has some understandable justification for adding into the beginning or is it just an poor and unfortunate design choice.
regards, Mikko
On Wed, Dec 18, 2019 at 11:08 AM Martin Ratinaud <martinratinaud@xxxxxxxxx> wrote:
Ok thanks MikkoMaybe I'm doing it wrong but here is my initial request
the number of samples is not really important to me. What does is that the compression algorithm does not add data at the beginning of the file, which it does nowDo you have any idea how I can achieve that ?-----------------------------------------------------------------------
Martin RATINAUD
-----------------------------------------------------------------------_______________________________________________On Wed, Dec 18, 2019 at 11:44 AM Mikko Olkkonen <molkko@xxxxxxxxx> wrote:If those are your requirements why dont you just stick to mp3? If your additional requirements would be that 1) audio quality perception remains OK and 2) number of samples remains intact then I believe that solution is nonexisting. You must relax either compression or quality requirement. My reasoning is as follows: you have a lot of samples in the original audio. If you have all those samples (in any reasonable format) in the output file you have large file again i.e. dont have much compression. In other words, if you want compression you must do more drastic processing e.g. transform the signal from "time domain" to "frequency domain" like mp3 does as far as I know. After such compression there is no any meaningful concept of a "sample" anymore. Thus you can not require that number of samples matches. The fact that sox reports number of samples for mp3 does not change this fact (maybe it should not report number of samples but some concept of a block mp3 uses). I believe that additional difficulty (e.g. the discrepancy you observed when you trimmed your signal) arises from aspects discussed in the sox manual section "Accuracy". regards, Mikko
_______________________________________________On Wed, Dec 18, 2019 at 6:02 AM Martin Ratinaud <martinratinaud@xxxxxxxxx> wrote:Ok and what would be one that- compresses the file a lot- is readable on the webThanks-----------------------------------------------------------------------
Martin RATINAUD
-----------------------------------------------------------------------_______________________________________________On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård <mans@xxxxxxxxx> wrote:Martin Ratinaud <martinratinaud@xxxxxxxxx> writes:
> Thanks for the tip!
>
> What codec should I use then ?
Depends on your needs. Obviously, you have to use a codec supported by
whatever is going to read the file.
--
Måns Rullgård
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
_______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
