VOGONS

Common searches


Reply 20 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Testing.. indeed! So far I've built and tested it on Ubuntu 18.04 Linux and Windows 10 with msys 1.0 + Git for Windows; I will test it on my raspberry pi in the coming days to get some ARM coverage.

Would hugely appreciate coverage on other platforms; Mac OSX, BSD? Other MinGW variants like msys 2.0.

Regarding mp3, there are no libraries that provide O(1) time seeking due to the way mp3 itself was designed. The impact to us is that when a game needs to seek to a time offset within a track, the libraries internally rewind to the start then play forward (decoding) as fast as possible until the desired time offset is achieved. The result is a noticeable delay during these seeks - even on very powerful systems. The bigger the seek the longer the wait.

Good examples are Stellar7 and Jones in the Fast Lane that hold all their cdda audio in a single audio track.

I've previously adapted Dr MP3 (https://github.com/mackron/dr_libs/blob/master/dr_mp3.h) into sdl sound l, but it didn't improve things, so I've left mp3 out to prevent folks from stumbling on this and having a bad experience.

(and even though I have a huge nostalgic spot in my heart for mp3, the ABX listening tests where mp3 loses by often wide margins to vorbis and aac - both of which in turn lose to Opus, tell me mp3 should remain a relic of the past 😀

Reply 21 of 138, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Good enough reasoning for me 😀
I have real life to attend to but maybe tomorrow afternoon I can test the oS X part on my side. Is there any example cue/bin/audio files set I can use to test?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 22 of 138, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I've never been happy with people converting their DOS audio to lossy but I could see it being useful in some circumstances, don't really see any reason for mp3 support but I'm sure someone will bitch of course. Probably someone using a game package they downloaded or unwisely converting all their DOS games to mp3 for some reason. I'm sure they'll be fine with converting their mp3s to ogg. heh

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 24 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Is mp3 even working in the existing DOSBox + SDL 1.0.3?

All of my tests in the past showed that 'imgmount' will succeed, but when it comes to actual audio playback, you just get silence. I'm just a sample size of one.. so maybe playback works on other systems?

Maybe there are huge boats of mp3-track refugees that this patch would leave stranded? I would hope not...

Yeah, I'm a big fan of lossless, and "archival" practices like adding parity data around important content, remote backups, and so on. On my PC, I use flac rips and png scans where space is plentiful, but I use my Pi for actual gaming, so I generate lossy tracks and jpeg scans for its SD card. The Pi is end of the line for that data!

Dominus, for testing, I'll be curious if it actually builds on Mac. Might need some fixes just to get it off the ground. As for games, I would try anything you have... feel free to transcode to flac and opus for now just to confirm functionality and test coverage. In your cue files, use FLAC or OPUS following the filenames instead of MP3. Not much to change.

Curious how it goes!

Last edited by krcroft on 2018-10-14, 22:50. Edited 1 time in total.

Reply 25 of 138, by olddos25

User metadata
Rank Member
Rank
Member

This patch seems pretty promising, good job!

Currently mod on several Discord servs and a forum, so you can trust me if you want a DOSBox mod here!
Other places to find me:
DraStic: http://drastic-ds.com (as dsattorney)
EPForums: http://www.epforums.org (as emulationfan)

Reply 26 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Feel free to throw a variety of frequencies, bit-depths, and mono-and-stereo at it too; I've tested it with 22 kHz mono FLACs as well as 96 kHz / 24-bit FLACs.
It will report a bit of diagnostics during the loading:

 CDROM: Loaded ./audio/track02-24-96.flac [96000 Hz 2-channel]

Reply 27 of 138, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Still banging my head on the dynrec problem.

I did some thinking on a part of the patch (the use values from cue file instead of duration). This is quite a big change if I understand it corrrectly. Wouldn't it break games with wrong cue files ?

What is the logic for using higher sample audio tracks ? The original files (from the CDROM) are limited and hardcoded at 44k. Why make it configurable ?

Water flows down the stream
How to ask questions the smart way!

Reply 28 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

Still banging my head on the dynrec problem.

I hope you get a breakthrough ... with enough banging, eh 😀

I did some thinking on a part of the patch (the use values from cue file instead of duration). This is quite a big change if I understand it correctly. Wouldn't it break games with wrong cue files ?

Multi-file CUEs with 00:00:00 MSF values are unaffected because the code takes the default path. This is going to be 99.9% of CUEs out in the wild given GOG releases use all zeros, and this is the recommended CUE format for users on the wiki. My own personal CUEs use all 00:00:00s, and I suspect everyone's here are too.

The small bit of code only goes active when MSF are non-zero (and only for the multi-file scenario, so BIN/CUE still uses the same code path too). So this code is only active when the game needs its audio track start times to match identically the raw CDROM layout.

I wish we wouldn't need this; I wish the audio file durations calculated by DOSBox would be sufficient to arrive upon the same MSF values as the raw CDROM - but unfortunately compressed audio tracks aren't exactly as long as their raw CD tracks, and thus DOSBox's MSF calculations are essentially always different than the raw CD layout... but fortunately 99% of games don't care 😀 So we only need this code path when games actually care.

What is the logic for using higher sample audio tracks ? The original files (from the CDROM) are limited and hardcoded at 44k. Why make it configurable ?

Opus outputs at 48 kHz fixed, regardless of the source content; so that's the hard technical reason. The good news is the code simply adjusts the mixer's data-rate based on the encoded audio-file.

This is determined runtime, so no config-file or user tweaks needed.

For users ripping their own CDs, they will definitely want to move up to Opus and gain the quality boost it offers. Vorbis & Speex are deprecated by Opus.

Sophisticated FLAC users might rip their audio CD's using 24-bit noise-shaping and SACD'd at 48 kHz to extract the maximum audible fidelity. For example, noise-shaping can improve the CDROM's noise floor from -96 dB to -120dB [ref], using a tool like SSRC.

This interesting article at Xiph describes how 48 kHz is optimal to satisfy the limits of human hearings, after shooting holes in the audiophile craze for 32bit-192kHz tracks.

The ability to support audio-files having rates other than 44.1 also opens up interesting use-cases. For example, say you set your DOSBox mixer to 22050 Hz, which all audio-channels get re-sampled to. So if you're using WAV or FLAC tracks, then you could actually re-encode those to 22050 as well, eliminate runtime re-sampling in DOSBox, and cut your disk-space in half! Yeah.. probably no one will care about this, but just wanted to mention it.

Last edited by krcroft on 2018-10-15, 21:17. Edited 3 times in total.

Reply 29 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

What about mp3 decoding? This was working with SDL-Sound, I think.

Tested MP3 playback with both DOSBox ECE-r4168 and DOSBox-r4168, and it's broken on both -- imgmount works, but silence during audio track playback. This is no doubt due to bugs in SDL_Sound 1.0.3.

Reply 30 of 138, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote:
Dominus wrote:

What about mp3 decoding? This was working with SDL-Sound, I think.

Tested MP3 playback with both DOSBox ECE-r4168 and DOSBox-r4168, and it's broken on both -- imgmount works, but silence during audio track playback. This is no doubt due to bugs in SDL_Sound 1.0.3.

AFAIK, DOSBox doesn't support playback MP3 out of the box. Wasn't there a problem with the GPL license or something?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 31 of 138, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Seems DOSBox never had this working in lockt stock code. Yhkwong had a patch for it in his Daum build and "Truth"made a patch at FLAC playback in DOSBox

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 32 of 138, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Yesterplay80 wrote:

AFAIK, DOSBox doesn't support playback MP3 out of the box. Wasn't there a problem with the GPL license or something?

As DOSBox is GPL licensed, any code that is weakly licensed by something like the MIT or three clause BSD license (therefore allowing relicensing to the terms of the GPL) or is license compatible as part of a larger derived work is good to go. Therefore, mp3 playback libraries such as MAD and MPG123 can be included as far as copyrights are concerned.

Patents were a concern with MP3 for quite some time, but I believe that they have all expired by now.

All hail the Great Capacitor Brand Finder

Reply 34 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Firtasik wrote:

Absolutely impressive work; I especially like the use of a neural network to detect when to switch between voice and music encoding!

The bitrate demo (playable in your browser) shows how far they've come to improve quality at a mere 9kbits/s. Amazing.

https://people.xiph.org/~jm/opus/opus-1.3/

To try 1.3 in DOSBox, just perform a fresh build with the patch above. The makefile will alway pull the latest Opus upstream sources, so users can alway run the latest codec revision.

Reply 36 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

MP3 decoding is inbound!
- A solution to the seek issue is in the works; I've been in touch with David Reid, the author of dr_mp3, regarding a cached fast-seek table implementation and design.
- dr_mp3 is now in the code and hooks for the seek table cache are ready.
- David is going to start implementing the seek table in dr_mp3 this weekend.

So this patch now supports:
- FLAC
- Opus
- Vorbis (fast STB implementation)
- MP3 (currently slow-seek, fast-seek in progress)

Attached are builds for Windows 10, Linux (Ubuntu 18.04), and macOS High Sierra. These all have zlib, libpng, and SDL_Net statically linked in as well, so they should be functionally-complete builds.

My macOS High Sierra VM doesn't support sound, so I'm hoping someone with actual hardware can kick the tires.
Feel free to PM for more instructions or testing help (ie: creating cue files, etc..).

Attachments

Last edited by krcroft on 2019-02-15, 19:27. Edited 1 time in total.

Reply 37 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Overhauled the "first-post" summarizing the progress thus far.

Also got rid of all the SDL2 / SDL-Mixer stuff, which was an early prototype (and unnecessary to mention now).

AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks

Reply 38 of 138, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Rev4 of the patch posted:
- replaces the previous CDROM double-load fix with ripsaw8080's one-line preemptive fix (https://sourceforge.net/p/dosbox/bugs/488/)
- now tracks the current playback position in equivalent Red Book sectors, so games that query it (like Jazz Jackrabbit) get the same MSF-value they would if a BIN/CUE were used
- includes some unused scaffolding to handle the up-coming MP3 fast-seektable, which will eventually land here: https://github.com/mackron/dr_libs/commits/dev_mp3

Reply 39 of 138, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I just tried the latest binary you provided here as well as a freshly compiled ECE build with the Rev. 4 patch and none of my games using CUE+ISO+OGG work anymore, neither do CUE+ISO+OPUS ones (I created some for testing). I always get a MSCDEX error when trying to mount one of these images. My latest build containing your previous patch without support for FLAC, OPUS and MP3 works, so I presume the problem lies within those new decoding features. Or me, doing something wrong. 😉

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)