"norm" effect causes intermittent truncation of MP3 output.

"norm" effect causes intermittent truncation of MP3 output.

[Scott Temby]

[-- Attachment #1.1: Type: text/plain, Size: 758 bytes --]

Hi,

When using "sox.exe *<source_file>.wav* -C 192.01
*<destination_file>.mp3* norm"
I've found the output is occasionally truncated (shorter duration than the
input, but matches up to that point).

I've tried this on a few systems, and while the fault is intermittent (not
linked to any particular input file or condition), it does repeatedly occur
(a few times in a "batch"). Immediately re-processing the same input files
often yields success, or at least, failures on different files. I've also
tried -C 192.2 to see if that was the issue, and it is not. removing "norm"
solves the problem, and I can reliably encode thousands of files without
truncation.

Hopefully there's an easy fix, if not, at least you are now aware of the
issue.

Regards,
Scott

[-- Attachment #1.2: Type: text/html, Size: 1954 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: "norm" effect causes intermittent truncation of MP3 output.

[Graff, David E via Sox-users]

[-- Attachment #1.1: Type: text/plain, Size: 1216 bytes --]

If you run the same batch of files two times using -R, do you get the same pattern of truncations both times?

  Dave Graff

From: Scott Temby <scottt@damsmart.com.au>
Reply-To: "sox-users@lists.sourceforge.net" <sox-users@lists.sourceforge.net>
Date: Thursday, June 17, 2021 at 10:03 AM
To: "sox-users@lists.sourceforge.net" <sox-users@lists.sourceforge.net>
Subject: [SoX-users] "norm" effect causes intermittent truncation of MP3 output.

Hi,

When using "sox.exe <source_file>.wav -C 192.01 <destination_file>.mp3 norm" I've found the output is occasionally truncated (shorter duration than the input, but matches up to that point).

I've tried this on a few systems, and while the fault is intermittent (not linked to any particular input file or condition), it does repeatedly occur (a few times in a "batch"). Immediately re-processing the same input files often yields success, or at least, failures on different files. I've also tried -C 192.2 to see if that was the issue, and it is not. removing "norm" solves the problem, and I can reliably encode thousands of files without truncation.

Hopefully there's an easy fix, if not, at least you are now aware of the issue.

Regards,
Scott

[-- Attachment #1.2: Type: text/html, Size: 4004 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: "norm" effect causes intermittent truncation of MP3 output.

[Peter P.]

Hi Scott,

encountered a similar thing and was told that the file length of mp3
files has a lower resolution as it stores data in chunks. If your .wav
is a bit longer than the mp3 but not long enough to fill up another
chunk at the end this might get discarded. Don't quote me on this, just
remembering something I asked here years ago...

* Scott Temby <scottt@damsmart.com.au> [2021-06-17 16:03]:
> Hi,
> 
> When using "sox.exe *<source_file>.wav* -C 192.01
> *<destination_file>.mp3* norm"
> I've found the output is occasionally truncated (shorter duration than the
> input, but matches up to that point).
> 
> I've tried this on a few systems, and while the fault is intermittent (not
> linked to any particular input file or condition), it does repeatedly occur
> (a few times in a "batch"). Immediately re-processing the same input files
> often yields success, or at least, failures on different files. I've also
> tried -C 192.2 to see if that was the issue, and it is not. removing "norm"
> solves the problem, and I can reliably encode thousands of files without
> truncation.
> 
> Hopefully there's an easy fix, if not, at least you are now aware of the
> issue.
> 
> Regards,
> Scott


> _______________________________________________
> 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

Re: [EXTERNAL] Re: "norm" effect causes intermittent truncation of MP3 output.

[Scott Temby]

[-- Attachment #1.1: Type: text/plain, Size: 1952 bytes --]

Thanks Peter,

I'm aware of the frame/chunk granularity at the end, I'm talking about serious truncation, e.g. 30min input wav, with a 4 minute MP3. Without the "norm" argument, everything reliably processes as expected.

Cheers,
Scott


On 18 Jun. 2021, 1:54 am, at 1:54 am, "Peter P." <peterparker@fastmail.com> wrote:
>Hi Scott,
>
>encountered a similar thing and was told that the file length of mp3
>files has a lower resolution as it stores data in chunks. If your .wav
>is a bit longer than the mp3 but not long enough to fill up another
>chunk at the end this might get discarded. Don't quote me on this, just
>remembering something I asked here years ago...
>
>* Scott Temby <scottt@damsmart.com.au> [2021-06-17 16:03]:
>> Hi,
>>
>> When using "sox.exe *<source_file>.wav* -C 192.01
>> *<destination_file>.mp3* norm"
>> I've found the output is occasionally truncated (shorter duration
>than the
>> input, but matches up to that point).
>>
>> I've tried this on a few systems, and while the fault is intermittent
>(not
>> linked to any particular input file or condition), it does repeatedly
>occur
>> (a few times in a "batch"). Immediately re-processing the same input
>files
>> often yields success, or at least, failures on different files. I've
>also
>> tried -C 192.2 to see if that was the issue, and it is not. removing
>"norm"
>> solves the problem, and I can reliably encode thousands of files
>without
>> truncation.
>>
>> Hopefully there's an easy fix, if not, at least you are now aware of
>the
>> issue.
>>
>> Regards,
>> Scott
>
>
>> _______________________________________________
>> 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

[-- Attachment #1.2: Type: text/html, Size: 2707 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: "norm" effect causes intermittent truncation of MP3 output.

[Jeremy Nicoll - ml sox users]

On 2021-06-17 14:00, Scott Temby wrote:
> Hi,
> 
> When using "sox.exe *<source_file>.wav* -C 192.01
> *<destination_file>.mp3* norm"
> I've found the output is occasionally truncated ...

I know you said that it's not predictable whether this happens
if you rerun the command for the same input file, but I'm
wondering if with -V3 there'd be any difference in the output
messages listed, between ok and truncated outputs?

-- 
Jeremy Nicoll - my opinions are my own


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: [EXTERNAL] Re: "norm" effect causes intermittent truncation of MP3 output.

[Jan Stary]

On Jun 18 03:00:06, scottt@damsmart.com.au wrote:
> I'm talking about serious truncation, e.g. 30min input wav,
> with a 4 minute MP3. Without the "norm" argument,
> everything reliably processes as expected.

Can you please post that wav file somewhere for download?

	Jan



_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: [EXTERNAL] Re: "norm" effect causes intermittent truncation of MP3 output.

[Scott Temby]

[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]

Hi,

Derp, I hadn't even thought to check the -V3 output. I've logged it
forever, but had removed the argument while trying to troubleshoot this
issue. On reviewing logs, it's happening when the temp storage runs out of
space - setting my temp environment variable to a larger disk (not system)
seems to have solved the problem. This also explains why it was an
intermittent problem, and no particular file would repeatedly cause the
issue.

Thanks for the prompt replies.

Scott

On Fri, 18 Jun 2021 at 05:55, Jan Stary <hans@stare.cz> wrote:

> On Jun 18 03:00:06, scottt@damsmart.com.au wrote:
> > I'm talking about serious truncation, e.g. 30min input wav,
> > with a 4 minute MP3. Without the "norm" argument,
> > everything reliably processes as expected.
>
> Can you please post that wav file somewhere for download?
>
>         Jan
>
>
>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 1700 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: [EXTERNAL] Re: "norm" effect causes intermittent truncation of MP3 output.

[Jeremy Nicoll - ml sox users]

On 2021-06-18 14:39, Scott Temby wrote:
> Hi,
> 
> Derp, I hadn't even thought ...

Who is "Derp"?

-- 
Jeremy Nicoll - my opinions are my own


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: unsubscribe

[Jeremy Nicoll - ml sox users]

On 2021-06-19 11:36, Stefan Ludwig wrote:
> Hello everybody,
> 
> this suerlist does not include a unsubscribe description
> 
> What do I have to do to unsubscribe?

Don't know... but probably the opposite of what you did to
subscribe in the first place.

That was possibly: log in to Sourceforge, find your way to
the page for this list, then click something ... so maybe
there's an unsubscribe option on their site?


-- 
Jeremy Nicoll - my opinions are my own


_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: unsubscribe

[Jeff Learman]

[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

I see a link to unsubscribe, which takes me here:
https://sourceforge.net/projects/sox/lists/sox-users/unsubscribe


On Sat, 19 Jun 2021 at 06:46, Jeremy Nicoll - ml sox users <
jn.ml.sxu.88@wingsandbeaks.org.uk> wrote:

> On 2021-06-19 11:36, Stefan Ludwig wrote:
> > Hello everybody,
> >
> > this suerlist does not include a unsubscribe description
> >
> > What do I have to do to unsubscribe?
>
> Don't know... but probably the opposite of what you did to
> subscribe in the first place.
>
> That was possibly: log in to Sourceforge, find your way to
> the page for this list, then click something ... so maybe
> there's an unsubscribe option on their site?
>
>
> --
> Jeremy Nicoll - my opinions are my own
>
>
> _______________________________________________
> Sox-users mailing list
> Sox-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sox-users
>

[-- Attachment #1.2: Type: text/html, Size: 1549 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users