(taking this back to pd-list)
On 2017-02-22 19:01, Lucas Cordiviola wrote:
I seems that [soundfiler] correctly ignores metadata. [soundfile_info] counts it as length. At least for .wav files.
[soundfile_info] assumes that everything after the (1st) "data" chunk is audio data. this is obviously not true if you have other chunks (cue, ...) coming after the audio. i talked to thomas, and it seems that the behaviour was actually intentional, meant to correctly handle truncated soundfile files (that would be shorted than indicated in the data-chunk header) as a side-effect, it would erroneously handle soundfiles that are longer than indicated in the data-chunk header.
i fixed this in iemlib's git repository[1]. i'll try to talk thomas into doing a proper release via deken.
fmasdr IOhannes
Good.
I think is better to use the data-chunk header, cuz broken sound files are far less common than files with metadata.
And broken sound files can be fixed, (copy audio and paste to a new file).
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, February 23, 2017 10:09 AM To: pd-list Subject: Re: [PD] soundfiler features
(taking this back to pd-list)
On 2017-02-22 19:01, Lucas Cordiviola wrote:
I seems that [soundfiler] correctly ignores metadata. [soundfile_info] counts it as length. At least for .wav files.
[soundfile_info] assumes that everything after the (1st) "data" chunk is audio data. this is obviously not true if you have other chunks (cue, ...) coming after the audio. i talked to thomas, and it seems that the behaviour was actually intentional, meant to correctly handle truncated soundfile files (that would be shorted than indicated in the data-chunk header) as a side-effect, it would erroneously handle soundfiles that are longer than indicated in the data-chunk header.
i fixed this in iemlib's git repository[1]. i'll try to talk thomas into doing a proper release via deken.
fmasdr IOhannes