headers
Chris Bagwell | 2 Oct 2004 23:37

Re: Prelease of SoX 12.17.6

I think I can reproduce this as well... Just want to make sure
we are seeing the same thing.  By "garbled" does it kinda sound
like pieces of the audio are being dropped?

If I run with "resample" effect, the audio file sounds like its
being sped up... With "polyphase", it sounds like its both sped
up and dropping portions of audio.

Hmmm, off to debug this.

Chris

On Sat, Oct 02, 2004 at 04:40:59PM -0400, Levi Bard wrote:
> Found an issue with the polyphase effect.  I'm using it to upsample
> raw audio from 44.1 to 48 KHz, and the output is now...garbled. 
> Unable to reproduce with 12.17.5.
> 
> Using:
> sox -t raw -r 44100 -c 2 -s -w input.fifo -t wav -r 48000 -c 2 -s -w
> output.wav polyphase
> 
> Running debian/sid on amd64.  I can post small samples if you like.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
(Continue reading)

Permalink | Reply |
headers
Levi Bard | 3 Oct 2004 00:15
Picon
Gravatar

Re: Prelease of SoX 12.17.6

On Sat, 2 Oct 2004 16:37:40 -0500, Chris Bagwell <chris <at> cnpbagwell.com> wrote:
> I think I can reproduce this as well... Just want to make sure
> we are seeing the same thing.  By "garbled" does it kinda sound
> like pieces of the audio are being dropped?
Yeah, sounds like parts are maybe being dropped, or pieces from other
places being mixed in.  But yeah, that's it.

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Permalink | Reply |
headers
Chris Bagwell | 3 Oct 2004 03:08

Re: Prelease of SoX 12.17.6

OK, I found the bug and made a new pre-release with the fix.  Some
effects were dropping samples.  Mostly, this was the resample effects.

You can get the new prerelease at
http://sox.sf.net/sox-12.17.6-pre2.tar.gz

Thanks for the report,
Chris

On Sat, Oct 02, 2004 at 06:15:53PM -0400, Levi Bard wrote:
> On Sat, 2 Oct 2004 16:37:40 -0500, Chris Bagwell <chris <at> cnpbagwell.com> wrote:
> > I think I can reproduce this as well... Just want to make sure
> > we are seeing the same thing.  By "garbled" does it kinda sound
> > like pieces of the audio are being dropped?
> Yeah, sounds like parts are maybe being dropped, or pieces from other
> places being mixed in.  But yeah, that's it.

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Permalink | Reply |
headers
Jimen Ching | 6 Oct 2004 10:34
Favicon

Re: Prelease of SoX 12.17.6

Chris,

I have an mp3 that has a large ID3v2 and scanning one ST_BUFSIZ didn't
find a valid frame.  The patch below will scan two ST_BUFSIZ length.

Perhaps a better approach would be to exclude these tag sizes from the
comparison?

--jc

Index: mp3.c
===================================================================
RCS file: /cvsroot/sox/sox/src/mp3.c,v
retrieving revision 1.7
diff -u -r1.7 mp3.c
--- mp3.c	30 Sep 2004 02:26:14 -0000	1.7
+++ mp3.c	6 Oct 2004 08:17:54 -0000
 <at>  <at>  -148,7 +148,7  <at>  <at> 

         while(mad_frame_decode(p->Frame,p->Stream)) {
             int tagsize;
-            if ((p->Stream->bufend - p->Stream->this_frame) < (INPUT_BUFFER_SIZE - ST_BUFSIZ)){
+            if ((p->Stream->bufend - p->Stream->this_frame) < (INPUT_BUFFER_SIZE - 2*ST_BUFSIZ)){

               /* we assume that, if the first frame fails, the file is not an MP3 file */

--

-- 
Jimen Ching (WH6BRR)      jching <at> flex.com     wh6brr <at> uhm.ampr.org

-------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
Chris Bagwell | 7 Oct 2004 18:25

Re: Prelease of SoX 12.17.6

On Tue, Oct 05, 2004 at 10:34:59PM -1000, Jimen Ching wrote:
> Chris,
> 
> I have an mp3 that has a large ID3v2 and scanning one ST_BUFSIZ didn't
> find a valid frame.  The patch below will scan two ST_BUFSIZ length.

Yes, I have an example MP3 with an ID3v2 that contains like 20k worth
of data.  12.7.5 pretty much died over that.  But I think there is
a bug in your patch.  If you only wanted to scan 2 ST_BUFSIZ, then it
should be:

  if ((p->Stream->bufend - p->Stream->this_frame) < (2*ST_BUFSIZ)){

At least, thats what my experience showed from my 20k ID3v2 test MP3. I've
just changed sox so that it attempts to scan past INPUT_SIZE_BUFFERS
bytes and that value equals 100k now.  That should get us past a majority
of ID3v2 tags.

> Perhaps a better approach would be to exclude these tag sizes from the
> comparison?

Ideally, I think we shoud peak into the MP3 frame data and see if the
file starts with "ID3" and if so read the length field and scan past
it that amount.  Then start looking for a valid MP3 frame.  That would
allow use to reduce INPUT_BUFFER_SIZE back to a more sane value.

Also, current code has another problem that should be fixed at the same
time.  If the ID3v2 tag is bigger then INPUT_BUFFER_SIZE, we don't have
the logic in place to read more buffers.  That may not be a big deal,
depending on how skipping ID3v2 tag was implemented.
(Continue reading)

Permalink | Reply |
headers
Chris Bagwell | 7 Oct 2004 20:11

Re: Prelease of SoX 12.17.6

Opps, I was wrong in my last email... Your code was correct, of course.
:-)

Anyways, I have modified my local copy to skip past an ID3v2 of upto
INPUT_BUFFER_SIZE (100k).

Still could user someone to fix that code.  Also, is it just me or
is the current code throwing away a possibly good frame of audio
data on files that don't have an ID3v2 at the beginning of the
audio file?

Chris

On Tue, Oct 05, 2004 at 10:34:59PM -1000, Jimen Ching wrote:
> Chris,
> 
> I have an mp3 that has a large ID3v2 and scanning one ST_BUFSIZ didn't
> find a valid frame.  The patch below will scan two ST_BUFSIZ length.
> 
> Perhaps a better approach would be to exclude these tag sizes from the
> comparison?
> 
> --jc
> 
> Index: mp3.c
> ===================================================================
> RCS file: /cvsroot/sox/sox/src/mp3.c,v
> retrieving revision 1.7
> diff -u -r1.7 mp3.c
> --- mp3.c	30 Sep 2004 02:26:14 -0000	1.7
(Continue reading)

Permalink | Reply |
headers
Chris Bagwell | 8 Oct 2004 02:04

Re: Prelease of SoX 12.17.6

Ok, let me correct myself one more time (I need to lay off the
cold medicine!).

OK, sox's mp3 reader will try to find a valid MP3 frame at beginning
of audio file.  If thats not found, it will look for an ID3 tag.
If a tag is found it attempts to jump past the tag.  If neither is
found, it skips ahead one byte and starts this process again.  This
means you can have any combination of garbage or tags at the beginning
of the file and it will handle it.

No audio data is lost (as I mentioned I was worried about).

Having said that, we still have the bug were it can only handle this
tag+garbage upto INPUT_BUFFER_SIZE bytes (100k).  If tag+garbage size
is greater then that then sox dies.  Thats the remaining part that I 
could use someones help with fixing.  Before today sox would die after 
tag+garbage of more then 8k.

Chris

On Thu, Oct 07, 2004 at 01:11:29PM -0500, Chris Bagwell wrote:
> Opps, I was wrong in my last email... Your code was correct, of course.
> :-)
> 
> Anyways, I have modified my local copy to skip past an ID3v2 of upto
> INPUT_BUFFER_SIZE (100k).
> 
> Still could user someone to fix that code.  Also, is it just me or
> is the current code throwing away a possibly good frame of audio
> data on files that don't have an ID3v2 at the beginning of the
(Continue reading)

Permalink | Reply |
headers
Jimen Ching | 8 Oct 2004 11:54
Favicon

Re: Prelease of SoX 12.17.6

On Thu, 7 Oct 2004, Chris Bagwell wrote:
>OK, sox's mp3 reader will try to find a valid MP3 frame at beginning
>of audio file.  If thats not found, it will look for an ID3 tag.
>If a tag is found it attempts to jump past the tag.  If neither is
>found, it skips ahead one byte and starts this process again.  This
>means you can have any combination of garbage or tags at the beginning
>of the file and it will handle it.

Yes.

>Having said that, we still have the bug were it can only handle this
>tag+garbage upto INPUT_BUFFER_SIZE bytes (100k).  If tag+garbage size
>is greater then that then sox dies.  Thats the remaining part that I
>could use someones help with fixing.  Before today sox would die after
>tag+garbage of more then 8k.

Well, the patch below might be considered a little too hacky by some.
I don't know how other handlers deal with these issues.  If you point me
to another handler that demonstrates the right way to fix this problem,
I'll give it a try.  The patch below works for the mp3's I have.

Note, the last else may be redundant since I'm using a goto.  When the
tagsize exceeds the remaining data, it would never execute the
mad_stream_skip (even without the else).  Feel free to remove it.

--jc
--

-- 
Jimen Ching (WH6BRR)      jching <at> flex.com     wh6brr <at> uhm.ampr.org

--------------------------------------------------------------------
(Continue reading)

Permalink | Reply |

Gmane