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 wrote: > Ok thanks Mikko > > Maybe 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 now > > Do you have any idea how I can achieve that ? > > ----------------------------------------------------------------------- > *Martin RATINAUD* > ----------------------------------------------------------------------- > > > On Wed, Dec 18, 2019 at 11:44 AM Mikko Olkkonen 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 >> wrote: >> >>> Ok and what would be one that >>> - compresses the file a lot >>> - is readable on the web >>> >>> Thanks >>> ----------------------------------------------------------------------- >>> *Martin RATINAUD* >>> ----------------------------------------------------------------------- >>> >>> >>> On Tue, Dec 17, 2019 at 2:50 PM Måns Rullgård wrote: >>> >>>> Martin Ratinaud 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@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/sox-users >>> >> _______________________________________________ >> Sox-users mailing list >> Sox-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sox-users >> > _______________________________________________ > Sox-users mailing list > Sox-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sox-users >