headers
Bartosz Bielawski | 15 May 2013 14:00
Picon

Stack Protector

Hi,

I've just cloned repo from GitHub and tried to build dynamic library
(Win32 DLL) using mingw32 under MacOSX. The build fails due to
unresolved symbols pointing at the stack protector. I tried to force
-fno-stack-protector flag during ./configure, but the
"-fstack-protector" follows in the CFLAGS cancelling the previous
setting.

The 1.0.25 version from tar.gz builds fine.

I've seen Erik's post on devel list for FLAC library about adding a
configure switch to disable stack protector. Is something like this
planned also for the new release of libsndfile?

And another quick question. I just run into a malformed mono WAV file.
It it's PEAK chunk it has too many records - 6 pairs (value, position)
instead of one. Is there any way to know libsndfile to go on with
reading as far as possible discarding all non-critical chunks?

Regards,
Bartosz
Permalink | Reply | 4 comments |
headers
Rahul Maji | 14 May 2013 10:54
Picon

Re: Create static .lib file

Kindly help please!! URGENT

On Tue, May 14, 2013 at 1:40 PM, Rahul Maji <rahulmj92@...> wrote:

> Hi,
>
> I want to create a static .lib file (libsndfile-1.lib) instead of a .dll
> file using MSVC++. Kindly help me to do so.
>
> A quick reply shall be appreciated.
>
> Thanks,
> Rahul.
>
Permalink | Reply | 1 comment |
headers
Rahul Maji | 14 May 2013 10:19
Picon

Re: Create static .lib file

Hi,
I want to create a static .lib file (libsndfile-1.lib) instead of a .dll
file using MSVC++. Kindly help me to do so.

A quick reply shall be appreciated.

Thanks,
Rahul.

On Tue, May 14, 2013 at 1:40 PM, Rahul Maji <rahulmj92@...> wrote:

> Hi,
>
> I want to create a static .lib file (libsndfile-1.lib) instead of a .dll
> file using MSVC++. Kindly help me to do so.
>
> A quick reply shall be appreciated.
>
> Thanks,
> Rahul.
>
Permalink | Reply | 0 comments |
headers
olivier tristan | 13 May 2013 10:00

Plans to release 1.0.26

Hi Erik,

Is there any plan to release version 1.0.26 of libsndfile ?

Thanks,

--

-- 
Olivier TRISTAN
uvi.net
Permalink | Reply | 2 comments |
headers
Chris Rienzo - Grasshopper | 30 Apr 2013 01:53
Favicon

FW: truncation errors in VOX ADPCM codec

-----Original Message-----
From: Rob Sykes [mailto:aquegg@...] 
Sent: Monday, April 29, 2013 4:39 PM
To: Chris Rienzo - Grasshopper
Subject: Re: [libsndfile-devel] truncation errors in VOX ADPCM codec

Sorry Chris, despite Erik having told me that the posting problem has been fixed, it obviously isn't yet...
Please could you forward this one to the list? Thanks in advance, Rob

----- Original Message -----

> From: Steve Underwood <steveu@...>
> To: libsndfile-devel@...
> Cc:
> Sent: Monday, 29 April 2013, 10:09
> Subject: [libsndfile-devel] Re: Fwd: truncation errors in VOX ADPCM 
> codec
> 

> What makes you think that all the files you have were generated by a 
> Dialogic card, rather than by buggy psuedo-Dialogic software?

Hi Steve,

That's not what I think -- I have a few files that I believe came from a Dialogic installation disc (they say
things like "Thank you for calling Dialogic Corporation, etc. "); and a few files from users, requesting
that their files, purportedly from vox recorders (but I didn't enquire as to the manufacturer), be
decoded correctly.

> to incorrect rounding. I suspect you have been fooled into trying to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Rienzo - Grasshopper | 28 Apr 2013 17:12
Favicon

Fwd: truncation errors in VOX ADPCM codec

From: Rob Sykes <aquegg@...<mailto:aquegg@...>>
Date: April 28, 2013, 10:35:49 AM EDT
To: Chris Rienzo - Grasshopper <crienzo@...<mailto:crienzo <at> grasshopper.com>>
Subject: Re: [libsndfile-devel] truncation errors in VOX ADPCM codec
Reply-To: Rob Sykes <aquegg@...<mailto:aquegg@...>>

Having spent some time refreshing myself on the subject of vox files, here's the current situation:

(From years ago) I have a number of sample files: some from Dialogic, and some that folk sent to me,
complaining that the vox implementation at the time was not right.  The current libsndfile
implementation decodes all but one of the files without problem. I also have a new problematic file from Chris.

With the 'truncation errors' version of the algorithm, Chris's file decodes without problem, but many of
the other test files don't (and the results suggest that Dialogic have used at least 3 variants of the algorithm).

To try to provide a good decode in all situations, I've implemented a new 'universal' vox decoder, and
associated this with SF_FORMAT_VOX_ADPCM in the patch here: https://dl.dropboxusercontent.com/u/8835547/sndfile-vox.patch

Also implemented in the patch, are two new formats (SF_FORMAT_VOX_ADPCM_A, SF_FORMAT_VOX_ADPCM_B) to
specifically select one of two algorithm variants (and not use the universal decoder). However, the
chances of anyone wanting to write a vox file these days are probably pretty slim, and if the universal
decoder lives up to its name, maybe the additional formats are unnecessary complication and should be dropped.

Cheers,
Rob
Permalink | Reply | 4 comments |
headers
Chris Rienzo - Grasshopper | 25 Apr 2013 22:15
Favicon

Re: truncation errors in VOX ADPCM codec

Hi Rob,

Thanks for the reply.  I definitely understand where you're coming from, however a decoder should be able to
decode a .vox file that a Dialogic encoder created.   If it can't, it's pretty useless to those of us in the CTI industry.

http://www.soft-switch.org/spandsp-doc/okiadpcm_page.html 

I can work-around this issue, but would prefer to have support in FreeSWITCH using libsndfile since we
already use libsndfile for many other formats and I don't really want to write a whole file format module
for a dying format that won't be used in a few years.

Regards,
Chris

-----Original Message-----
From: Rob Sykes [mailto:aquegg@...] 
Sent: Thursday, April 25, 2013 3:18 PM
To: Chris Rienzo - Grasshopper
Subject: Re: [libsndfile-devel] truncation errors in VOX ADPCM codec

----- Original Message -----

> Comparing the two decoders, I noticed spandsp exactly follows the 
> algorithm as described by Dialogic while libsndfile improves on the 
> implementation but does not reproduce the truncation errors.   For example:

Hi Chris,

The list seems to be rejecting my mails at the moment, so replying directly.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Rienzo - Grasshopper | 25 Apr 2013 15:03
Favicon

truncation errors in VOX ADPCM codec

Hi,
I recently added .vox (Dialogic ADPCM raw file format) support to FreeSWITCH using libsndfile and noticed
the library is not decoding files encoded by a Dialogic encoder properly.  I verified using spandsp's
ADPCM decoder which does not have this issue.  See
http://git.freeswitch.org/git/freeswitch/tree/libs/spandsp/src/oki_adpcm.c#n152 for spandsp
(LGPL) implementation.

Comparing the two decoders, I noticed spandsp exactly follows the algorithm as described by Dialogic
while libsndfile improves on the implementation but does not reproduce the truncation errors.   For example:

Spandsp:
ss(n) = 55
L(n) = 7
d(n) = 55 + 55/2 + 55/4 + 55/8 = 101
d(n) << 4 = 1616

libsndfile:
ss(n) << 4 = 880
L(n) = 7
s = 7 << 1 | 1 = 15
d(n) << 4 = ((880 * 15) / 8) & 65520 = 1648

I can submit a patch that implements the decoder similarly to spandsp, but wanted to know if this solution
would be accepted.

Chris
Permalink | Reply | 0 comments |
headers
Felix Homann | 4 Apr 2013 19:34
Picon

Large file support and the ultimate sanity check on Android

Hi Erik,
I've been trying to get libsndfile working on Android, lately. Building
libsndfile went fine after adding a check for Android in
programs/sndfile-play.c (see, my simple fix on
https://github.com/showlabor/libsndfile ). It even build with
flac/ogg/vorbis using the respective sources from git.
Once I tried using it on Android it would fail due to the "Ultimate sanity
check" in sndfile.c/sf_open ():

/* Ultimate sanity check. */
assert (sizeof (sf_count_t) == 8) ;

Digging a bit through and my configure log and configure.ac I found that
the Android toolchain "does not seem to support 64 bit file offsets."
That's very saddening and comes as a big surprise after managing the build.

So here are a couple of questions:

1. Do you know which previous version of libsndfile might still work
with sizeof (sf_count_t) == 4?
2. Why does only sf_open() perform the ultimate sanity check and not
sf_open_fd() ?
3. Do you know of any workarounds for Android?
4. Wouldn't it be better to let configure fail if there's no large file
support if you can't sf_open a file anyway?

Thanks,

Felix
(Continue reading)

Permalink | Reply | 10 comments |
headers
Karl Lindén | 4 Apr 2013 12:24
Picon
Gravatar

[PATCH] configure script should honour htmldocdir

Hi!
I think the configure script should honour --htmldir to specify the
path to where the html documentations should be located because that
is the default for autotools. Currently it uses the non-standard
htmldocdir variable which overrides the standard htmldir variable.

The patch will remove the setting of
$prefix/share/doc/libsndfile1-dev/html. I can understand that approach
as it distinguishes between the "normal" documentation and the html
developers documentation, but the --htmldir gives a more standardized
and flexible way of specifying it. Besides, the output of configure
--help would then be more accurate.

I'm attaching the patch in this mail. The patch is against the latest
git version.

Kind regards,
Karl Lindén
Permalink | Reply | 2 comments |
headers
Andrew Ekstedt | 4 Apr 2013 06:23
Picon

sndfile-cmp fails to detect when first file is shorter than second file

I discovered this bug when i compared the first track of an album to
the entire album.
Attached is a CD-quality wav file which is 0 samples long. Comparing
this file, null.wav, to any other file with sndfile-cmp will give an
error if null.wav is the second file, but will not give an error if
null.wav is the first file.

$ sndfile-cmp something.wav null.wav
sndfile-cmp: PCM data lengths of files something.wav and null.wav differ.
$ echo $?
1
$ sndfile-cmp null.wav something.wav
$ echo $?
0
$

Andrew
Permalink | Reply | 5 comments |

Gmane