On Wed, Oct 25, 2023 at 10:10:32AM +0600, Maria Morisot wrote:
>
> > that you're using correct lengths though, it is possible to get things
> > wrong and break programs.
>
> I was careful to look at the buffer lengths being written and to match them
> in strlcpy and snprintf. I peeked at the
Hi Maria,
Maria Morisot wrote on Wed, Oct 25, 2023 at 09:44:17AM +0600:
> because the compiler said to.
Never trust a linter blindly.
A linter is a tool to automate searching for some kinds of issues.
For every candidate, you still need to engage your brains to figure out
- whether it's an
I thought xenocara was kind of incorporated into the OpenBSD project. Thanks
for responding. I think when I started out a month ago, my main issue was
having hangups in the kernel from running xfce. I've since migrated to cwm and
am much happier than when using xfce on Linux.
I have high
On 2023-10-25, Maria Morisot wrote:
> Basically I just changed all instances of strcpy and sprintf to use strlcpy
> and snprintf, because the compiler said to.
>>
>> This sort of change should go upstream rather than in ports. Be careful
>> that you're using correct lengths though, it is
On Tue, Oct 24, 2023 at 10:42:06PM +0200, Jan Stary wrote:
> On Oct 24 22:09:02, a...@caoua.org wrote:
> > faad -w file.m4a | cat >file.wav
> > results in a file with zero-size data chunk (because faad couldn't
> > seek to the beginning of the file to fixup the header). aucat,
> > audacious,
On Tue, Oct 24, 2023 at 11:11:01PM +0600, Maria Morisot wrote:
>
> Forgive me if I'm dense, but I'm a better artist than I am a
> programmer. I'm trying to follow you though. I understand why you
> cannot seek in a pipe, but I do not understand why that affects
> playback of a MS Wav file through
On Oct 25 12:10:07, maria.mori...@icloud.com wrote:
>
> > SoX's play --ignore-length can play it.
> >
> SoX's --ignore-length appears in a few formats, as far as the wav format
> goes, the code comments suggest it is implemented to handle 32-bit wav files
> greater than 2GB. It seems you just
I'll check out SoX's --ignore-length option and see if I can figure out what
they are doing there.
What I'm more concerned with than the implementation is which behavior seems
more correct; to try to play at the specified rate or to just ignore and play
at the default settings.
--
Google
> SoX's play --ignore-length can play it.
>
SoX's --ignore-length appears in a few formats, as far as the wav format goes,
the code comments suggest it is implemented to handle 32-bit wav files greater
than 2GB. It seems you just found a happy side effect.
> that you're using correct lengths though, it is possible to get things
> wrong and break programs.
I was careful to look at the buffer lengths being written and to match them in
strlcpy and snprintf. I peeked at the source for instances of strcpy and found
a lot in xenocara; less in the
Basically I just changed all instances of strcpy and sprintf to use strlcpy and
snprintf, because the compiler said to.
>
> This sort of change should go upstream rather than in ports. Be careful
> that you're using correct lengths though, it is possible to get things
> wrong and break programs.
On Oct 24 22:09:02, a...@caoua.org wrote:
> faad -w file.m4a | cat >file.wav
> results in a file with zero-size data chunk (because faad couldn't
> seek to the beginning of the file to fixup the header). aucat,
> audacious, audacity and sox can't play it; mpv, and ffplay can
SoX's play
On 2023-10-24, Lucretia wrote:
> I made my first patch!
>
> To devel/dwz, I'm not sure how to submit it, or if it's even useful to anyone.
>
> Basically I just changed all instances of strcpy and sprintf to use strlcpy
> and snprintf, because the compiler said to.
This sort o
On Wed, Oct 25, 2023 at 12:06:05AM +0600, Maria Morisot wrote:
>
> I don't have a test machine and I'm trying to keep my installation
> as simple as possible, but if anyone wants to try piping a wav file
> into mplayer or ffplay, I'd be interested in the results. Does it
> work?
faad -o file.wav
I don't have a test machine and I'm trying to keep my installation as simple as
possible, but if anyone wants to try piping a wav file into mplayer or ffplay,
I'd be interested in the results. Does it work?
> You're right. The .wav headers require to lseek(2) within the file
> which doesn't work on a pipes. It could work on certain files which
> headers are placed in a way lseek(2) doesn't need to move the file
> pointer.
> You could try to modify aucat to skip the lseek(2) calls if it
> wouldn't
On Tue, Oct 24, 2023 at 09:15:57PM +0600, Maria Morisot wrote:
> It is my understanding that wav files contain the headers necessary for a
> program to adjust the audio settings for play, or to do the software process
> necessary to reformat the input to the audio device.
>
> It doesn't make
It is my understanding that wav files contain the headers necessary for a
program to adjust the audio settings for play, or to do the software process
necessary to reformat the input to the audio device.
It doesn't make sense to have the wav headers if they aren't going to be used.
Tell me if
On Tue, Oct 24, 2023 at 05:10:53PM +0600, Lucretia wrote:
>
> a bit off-topic, but:
> gethsemane$ faad -w Tori_Amos/The_Beekeeper/03* | aucat -i - -h wav
> makes Tori sound like Minnie Mouse. How can I fix this?
>
you've make faad and aucat use the same data format, ex:
faad -d -f2 -w
I made my first patch!
To devel/dwz, I'm not sure how to submit it, or if it's even useful to anyone.
Basically I just changed all instances of strcpy and sprintf to use strlcpy and
snprintf, because the compiler said to.
This is like crack cocaine to me.
a bit off-topic, but:
gethsemane
20 matches
Mail list logo
