*.wv support

[kevinarcz]

Hi,
is there a possibility to support *.wv files?

Thank You

[GoneMAD]

wavepack is already one of the supported formats

[kevinarcz]

If I want to play a wv file, the player will quit.

[GoneMAD]

email one of the files with issues [e-mail] (or post some where and link so i can download) Your file is most likely not a valid wavpack file and its crashing the audioengine

[kevinarcz]

I sent email, thank you very much.

[GoneMAD]

so it looks like that file you sent was 32bit 192khz which is insane overkill especially for something recorded in the 80s / 90s. It doesnt crash for me but it doesnt really play which makes me believe the audioengine (ffmpeg in particular) cannot handle this particular format. 44khz / 16 bit wv do work correctly

There are no planned audioengine updates until after 3.0 is done. This would include updating ffmpeg but that doesnt guarantee it would make this file work. I recommend using a more reasonable/supported format like FLAC

[GoneMAD]

also fyi android doesnt output higher than 48khz (unless that changed in android 10)

[kevinarcz]

May 5, 2020 9:07:35 GMT -5 GoneMAD said:

so it looks like that file you sent was 32bit 192khz which is insane overkill especially for something recorded in the 80s / 90s. It doesnt crash for me but it doesnt really play which makes me believe the audioengine (ffmpeg in particular) cannot handle this particular format. 44khz / 16 bit wv do work correctly

There are no planned audioengine updates until after 3.0 is done. This would include updating ffmpeg but that doesnt guarantee it would make this file work. I recommend using a more reasonable/supported format like FLAC

Thank you for the quick reply. The files are part of a collection. Flac files, 16bit and 24 bit, can be played without any problems.

also fyi android doesnt output higher than 48khz (unless that changed in android 10)

Playing music on Android is secondary, I play it from the phone only in the car.


Thank you for your reply

[MotleyGord]

May 5, 2020 9:18:18 GMT -5 GoneMAD said:

also fyi android doesnt output higher than 48khz (unless that changed in android 10)

Except through USB DAC devices, these are supported at least to 24 bit and up to 192kHz from what I can see with my DAC. Possibly higher with apps that support with their own engine on devices better than what I have. But all other apps tend to have very limited UI and are not very user friendly as a result.

[GoneMAD]

May 5, 2020 18:02:30 GMT -5 MotleyGord said:

May 5, 2020 9:18:18 GMT -5 GoneMAD said:

also fyi android doesnt output higher than 48khz (unless that changed in android 10)

Except through USB DAC devices, these are supported at least to 24 bit and up to 192kHz from what I can see with my DAC. Possibly higher with apps that support with their own engine on devices better than what I have. But all other apps tend to have very limited UI and are not very user friendly as a result.

Sorry looks like i was wrong OR (which is more likely) google just took forever to update their documentation to reflect it. A year or 2 i looked at the docs stated most of the playback apis were limited to 48hz but it looks like that was changed in android 6.0

As of API Build.VERSION_CODES.M, sample rates up to 192kHz are supported for AudioRecord and AudioTrack

As for DACS, doesnt matter what the DAC supports if the api being used for playback doesnt support it. Using a DAC on a pre android M device is not going to get you 192khz output

Whenever i eventually finish 3.0 (and its subsequent patches) i'll start working on a new audioengine that'll support floating point output and not downsample sample rate. Googles push to use the storage access framework for all disk access is also another big reason for having to do a rewrite (but also JRTStudio owns the IP to gmmp's audioengine as of a few years ago, so it doesnt make sense to do significant rework to something i no longer own)