Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we move away from .wav files? #485

Closed
Allan-N opened this issue Feb 11, 2025 · 8 comments · Fixed by #492
Closed

Can we move away from .wav files? #485

Allan-N opened this issue Feb 11, 2025 · 8 comments · Fixed by #492

Comments

@Allan-N
Copy link
Collaborator

Allan-N commented Feb 11, 2025

The app_rpt code creates/uses .wav files for stored audio. This choice isn't very "Mac" friendly. Can we look into using (or at least offering) another format?

@InterLinked1
Copy link
Member

I think there are a few things to unpack here.

The files generated by a telephony system (or consumed by one) typically aren't meant to be interacted with by end users directly. It sounds like the files you are talking about might be intended for that purpose though.

WAV files are pretty standard, and can be played by pretty much everything since it's just raw audio. If it isn't Mac friendly, that sounds like a Mac problem specifically and something that should be addressed there (I'm honestly surprised none of the Mac software would support it). It's possible maybe it's something else here in a wav container, but I don't know the specifics here.

If this is the default now, I don't think the format should be changed, but perhaps the user could be allowed to control it. Asterisk supports a variety of formats. Probably the most versatile solution is to allow the user to specify the filename, in a similar manner to usage of MixMonitor, where it will then use that format. You could then, say, save as mp3 if you wanted to (not that you would want to!)

@Allan-N
Copy link
Collaborator Author

Allan-N commented Feb 13, 2025

It sounds like the files you are talking about might be intended for that purpose though.

The files I'm talking about are those associated with the "archivedir" setting.

If it isn't Mac friendly, that sounds like a Mac problem

AFAIK, the issue has been a Microsoft licensing thing and it's been a problem for a very long time. In short, you can't play .wav files on a Mac without first converting the file to a supported format.

perhaps the user could be allowed to control it.

Yes, being able to specify an alternate format (e.g. .mp3) would be great. Just need a new setting to specify the archive format :-)

@W6HBR
Copy link
Collaborator

W6HBR commented Feb 13, 2025

I play WAV files on my Mac all the time. Both Apple Music and Quicktime player will play WAV files natively on a Mac and both apps are installed by default. WAV files are probably the most universal format around that every platform supports.

Since the archivedir files are separated by keyup, I like to use VLC media player to play a series of them together to be able to listen to a full QSO or net. VLC is available for Mac, Windows, Linux, et al.

@InterLinked1
Copy link
Member

It sounds like the files you are talking about might be intended for that purpose though.

The files I'm talking about are those associated with the "archivedir" setting.

What are these files actually intended for? Is it expected users would copy them over and listen to them?

If it isn't Mac friendly, that sounds like a Mac problem

AFAIK, the issue has been a Microsoft licensing thing and it's been a problem for a very long time. In short, you can't play .wav files on a Mac without first converting the file to a supported format.

Strange... even for other formats using the wav container? Even with VLC?

perhaps the user could be allowed to control it.

Yes, being able to specify an alternate format (e.g. .mp3) would be great. Just need a new setting to specify the archive format :-)

Actually, it seems it's not writing a true wav file: https://github.com/AllStarLink/app_rpt/blob/bbb6a19ad4b851c4492c011bba91c699c314ee31/apps/app_rpt.c#L2965C46-L2965C51

It's specifying wav49, which is really a gsm file in a wav container.

Personally, like most people that deal with telephony, I think this is disgusting. There's no good reason to use a gsm file, the quality is horrible. ulaw would be better. Then again, radio transmissions probably aren't the best quality anyways, so maybe Jim didn't think it mattered :)

So I suspect the fact that it's really a gsm is why you can't play it, and I wouldn't be surprised if native Windows tools couldn't either. But most telephony formats can't be played by consumer operating systems since that's not the purpose. It probably makes sense to choose the format based on the criteria we're optimizing for here (size, compatibility, quality, etc.)

@Allan-N
Copy link
Collaborator Author

Allan-N commented Feb 13, 2025

@InterLinked1 wrote:

What are these files actually intended for? Is it expected users would copy them over and listen to them?

https://wiki.allstarlink.org/wiki/Archivedir

@W6HBR wrote:

I play WAV files on my Mac all the time. Both Apple Music and Quicktime player will play WAV files natively on a Mac and both apps are installed by default. WAV files are probably the most universal format around that every platform supports.

and @InterLinked1 wrote:

Actually, it seems it's not writing a true wav file: ... It's specifying wav49, which is really a gsm file in a wav container.

Well, maybe that explains why I got a "The file isn’t compatible with QuickTime Player" error.

... and being able to specify a format that works for me seems like it would be a good thing.

@Allan-N
Copy link
Collaborator Author

Allan-N commented Feb 13, 2025

Oh, it may have been .wmv files that Apple had issues with.

@W6HBR
Copy link
Collaborator

W6HBR commented Feb 13, 2025

Hmm... I never knew they were a gsm file in a wav container. Makes me wonder if that is part of the problem with the techno sounding files that some are encountering. Maybe something changed with installed codecs or settings.

For me, on ASL1 and ASL3, I've had no issues with just copying the files and playing on either PC or Mac.

@jxmx
Copy link
Member

jxmx commented Feb 15, 2025

Looks like it's a trivial fix to use wav instead of wav49. Other parts of app_rpt.c are using wav directly.

jxmx added a commit that referenced this issue Feb 15, 2025
Allan-N pushed a commit that referenced this issue Feb 19, 2025
Allan-N pushed a commit that referenced this issue Feb 19, 2025
This change means that one will be now be able to specify an audio
recording format other than "wav49".

Resolves #485
Allan-N pushed a commit that referenced this issue Feb 19, 2025
This change means that one will be now be able to specify an audio
recording format other than "WAV".

Resolves #485
Allan-N pushed a commit that referenced this issue Feb 19, 2025
This change means that one will be now be able to specify an audio
recording format other than "WAV".

Resolves #485
Allan-N pushed a commit that referenced this issue Feb 20, 2025
This change means that one will be now be able to specify an audio
recording format other than "WAV".

Resolves #485
Allan-N pushed a commit that referenced this issue Feb 20, 2025
This change means that one will be now be able to specify an audio
recording format other than "WAV".

Resolves #485
Allan-N pushed a commit that referenced this issue Feb 20, 2025
This change means that one will be now be able to specify an audio recording format other than "WAV".

Resolves #485
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants