VOGONS

Common searches


Reply 40 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Can you PM me your CUE files you tried? The binaries work great on multiple systems I've tried, so there's probably something tiny not right. In any case, it will be good to figure it out and prevent/fix it going forward.

Reply 41 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

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. 😉

Yesterplay80 and I did some digging: huge thanks to him for figuring his particular Ogg files were the issue. They were using a non-standard encoding to support multiple internal streams (such as multiple language tracks), called "Ogg Skeleton Metadata Bitstream https://xiph.org/ogg/doc/skeleton.html, which is not understood by the stb_vorbis decoder.

Yesterplay80 re-encoded his tracks with the standard single-stream Vorbis settings and confirmed good playback of the other formats - so we're in good shape. All GOG/STEAM releases us the same standard single-stream encoding, so this is hopefully a one-off issue.

In the meantime, I've submitted an issue to stb_vorbis: https://github.com/nothings/stb/issues/676.
Edit: I've submitted a patch to stb_vorbis adding detection of skeleton metadata [url]https://github.com/nothings/stb/pull/678/files[url]
Edit 2: the patch has been accepted and it now part of stb_vorbis

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

Reply 42 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Quick update on proper mp3 handling: the rev4 patch supports mp3 stand-alone "always on" via dr_mp3.h as opposed to using libmp321 or libMAD.

Seeking is currently too slow for playability. For example, visiting Monolith Burgers in Jones in the Fast Lane results in a several-second pause while the decoder reads the mp3 all the way from the start through to the 30 minute mark in the stream.

These last couple weeks Dave has been improving the seek behavior of dr_mp3.h, including frame-header-only reading (as opposed to decoding the entire frame), and just this weekend got the initial fast-seek table handling in place for CBR streams.

I've added corresponding support on the DOSBox side which takes care of loading and updating a seek table file, and its now performing at proper "instantaneous" levels for transparent game play.

The next step is to add VBR handling, which will complete the fast seek implementation and make it ready for general use/testing.

At that point I'll generate a rev5 patch for us to try, which will be functionally complete and we can review for any other maintenance or structural issues.

Reply 43 of 145, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I really need to learn how to replace ogg/vorbis with this one... Exult is also relying on these two libs and replacing it with a single header... would be great 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 44 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Dominus, we can certainly work on it! It's surprising how nice it is having everything self-contained, as I've been tinkering on this audio code a while.

Yesterplay80, I've submitted a pull request to stb_vorbis adding detection of Ogg skeleton metadata: https://github.com/nothings/stb/pull/678/comm … d4d53229b585d72
We've already got it in the DOSBox patch (and I have no intention of taking it out because it's a helpful clarification), but hopefully other projects might also benefit. Thanks again for catching it!

Reply 45 of 145, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I'll see that I clear my head and desktop space and will take a look at how it is implemented. As we, Exult, already use ogg/vorbis directly (we used to do it via SDL_Mixer) it might even be easier to implement.
As soon as I'm ready I'll pm you. Many thanks!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 46 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

With the improved seek performance now implemented in dr_mp3, I ran some benchmarks.

opus seeks take < 0.4 ms, mp3 < 0.9 ms, wav and flac roughly 2 ms, and vorbis < 7 ms.

Given a 70fps game, that's 14ms per frame, so all of these codecs can complete the seek within a single frames' time, which is great.

Even though vorbis is still roughly an order of magnitude slower than opus and mp3, keep in mind PCM-exact seeking in vorbis is extremely difficult, as documented by Sean Barrett: http://nothings.org/stb_vorbis/ogg_seek.txt, who's the author of stb_vorbis. He later went onto offer a $5000 USD bounty for an efficient implementation - and eventually got it (https://github.com/nothings/stb/issues/117). So sub-7ms is still great.

I think the other good news is Opus is the clear leader - so the Xiph authors (https://github.com/xiph/opus/blob/master/AUTHORS) have solved more than just making a great quality/bitrate codec.

stb_vorbis
CDROM: seek(34485024) took 5.321646 ms
CDROM: seek(183027936) took 5.928965 ms
CDROM: seek(337883616) took 6.493050 ms
CDROM: seek(1759296) took 4.413499 ms

dr_mp3 pre-generated seekpoints, 1-every-10 mp3 frames
CDROM: seek(35574000) took 0.818466 ms
CDROM: seek(189785232) took 0.778496 ms
CDROM: seek(334329744) took 0.396842 ms
CDROM: seek(6115200) took 0.266457 ms

sdl_sound's WAV decoder
CDROM: seek(32165952) took 0.015657 ms
CDROM: seek(186301920) took 2.208570 ms
CDROM: seek(339344208) took 2.146041 ms
CDROM: seek(200296320) took 2.193242 ms
CDROM: seek(5268480) took 0.014133 ms

dr_flac pre-generated seekpoints, one every 1s of audio
CDROM: seek(29124816) took 2.617673 ms
CDROM: seek(189147840) took 2.730340 ms
CDROM: seek(336470064) took 2.725294 ms
CDROM: seek(1759296) took 0.343579 ms

xiph opus
CDROM: seek(35574000) took 0.332695 ms
CDROM: seek(189147840) took 0.356307 ms
CDROM: seek(333777024) took 0.365779 ms
CDROM: seek(5268480) took 0.238305 ms

Reply 47 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

For opus, the current patch internally compiles and links libogg and libopus source packages from Xiph. The other codes (wav, flac, mp3, and vorbis) are single-header implementations embedded as part of the source tree.

David Reid, the developer of dr_flac.h and dr_mp3.h used in this patch, had started work on dr_opus.h. So when that's ready in the coming months I will be transitioning this patch to use that in place of the existing libogg and libopus packages.

Reply 48 of 145, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie

Hey krcroft,

Many Thanks for the Audio Patch. I added and Integrate this in my SDL 2.05 Build. Base Fork came from dugan
My DosBox fork. OpenGL 3 GLSL shaders, FluidSynth (SDL2)

My Personal Github Page: https://github.com/MartyShepard/Dosbox--Optionals-

Reply 49 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Marty2dos wrote:

Hey krcroft,

Many Thanks for the Audio Patch. I added and Integrate this in my SDL 2.05 Build. Base Fork came from dugan
My DosBox fork. OpenGL 3 GLSL shaders, FluidSynth (SDL2)

You're welcome Marty! Thanks for the heads up regarding your SDL 2.0 port as well; I was only aware of NY00123's till now, which is here:
An adaptation to SDL 2.0 (Alpha-level Android build attached)

Reply 50 of 145, by bam

User metadata
Rank Newbie
Rank
Newbie

Hi guys!
I'm trying to add IMGMOUNT support to Flathub's DOSBox build: https://github.com/flathub/com.dosbox.DOSBox/issues/12.
How I see it, I have following options:

  • build vanilla DOSBox against with old unmaintained SDL1 version of SDL_sound (default option)
  • try your patches
  • consider existing SDL2 solutions (which means patching again)

To be honest, I'm doubt to choose any..

What option would you suggest to me?
Please keep in mind that Flathub apps are supposed to be exposed for wider audience (since it's distro-agnostic solution).
Thanks!

Last edited by bam on 2019-01-03, 17:02. Edited 1 time in total.

Reply 51 of 145, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Option 1 just works 😉 (and to clarify, not imgmount is misssing but the ability to use mixed binary and conpressed aufio images).
The best option would be to not use mixed images but images with the audio tracks in the bin.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 52 of 145, by bam

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

not imgmount is misssing but the ability to use mixed binary and conpressed aufio images

Well, I was not able to mount it even without data track:

FILE "LBA2.OGG" MP3
TRACK 01 AUDIO
INDEX 01 00:00:00

Reply 53 of 145, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yeah, sorry, let me elaborate, the compressed audio tracks need SDL_sound. Normal bin/cue images that have their audio tracks in the bin file work fine.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 55 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
bam wrote:
Dominus wrote:

Option 1 just works 😉

Well, doesn't the others work also? SDL_sound looks more like abandonware..

.

sdl1_sound was abandoned in 2008. Getting ogg Vorbis support working in a custom bsrebones self contained environment (which flatpak's runtime environment virtualizes for every app), takes some effort to get your include paths, cflags, and config options right.

For option 2 (the patch), the above motivated the move to eliminate the dependence on sdl_sound and the vorbis libraries in this patch, in favor of local and embedded smaller decoders, as well as building the opus libraries internally.

My guess is you will be offering baseline builds of 0.74.2 and/or SVN DOSBox in flathub? In that case applying this patch and builing should "just work", although I personally havent tried a flatpak build. Happy to test if you point me at something!

Reply 56 of 145, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

While I appreciate kcroft's effort and hope it gets accepted, using the default (option 1) is the best way to go forward if you want to offer it to others. IMO keeping it as close to the original release is important. And yes, while SDL_sound for SDL 1.2x was abandoned, it just works (mostly) for the scope of Dosbox.
Using these patches will only make users of your build into unsuspecting beta testers and when they come to report to the Dosbox devs they will be shut down because they are using unsupported builds.

And I had the impression you (bam) didn't want to apply patches 😀

I hope kcroft's patches get into Dosbox 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 57 of 145, by bam

User metadata
Rank Newbie
Rank
Newbie

@Dominus, agree.
After all, it's Dosbox devs duty, not mine, to pull clever patches as this and to not being dependent on abandonware forever..

krcroft wrote:

Getting ogg Vorbis support working in a custom bsrebones self contained environment (which flatpak's runtime environment virtualizes for every app), takes some effort to get your include paths, cflags, and config options right.

@krcroft, what do you mean? I see no hassle at all here: https://github.com/Pixelnarium/flatpak/blob/m … DOSBox.json#L28, not even sure those "smpeg" flags are required. Didn't test it yet, though.

Please, treat me right - I appreciate your work and hope it will take proper place.
But for now, I feel I should follow "mainstream way" - that is, which Devs chose. How ugly would it is 🙁

Reply 58 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Well said Dominus, and I fully agree - if these flatpak builds will be distributed generally beyond Bam's use and supported by the DOSBox team, then I fully recommend strictly using the released 0.74.2 source linked against release-only versions of sdl sound (1.03) libogg and libvorbis to ensure reproduceabilty of bugs.

Bam, appologies if my explanation came of denigrating; certainly that was not intended. I personally found that when I uninstall sdl, sdl sound, sdl net, ogg, and vorbis libraries from my installed distro - and then perform custom builds of them each installed to a unique location, it can be tricky to get DOSBox configured to both see their headers and link with their libraries (typically needs a combination of cflags, ldflags, and ./configure arguments).

Where as some packages might include a configurable option for each external dependency, like: --with-sdl /path1 --with-sdl-sound /path2 --with-sdl-net /path3 --with-ogg /path4 --with-vorbis /path5 ... and so on, with autotools taking care of adding those include and link paths to cflags and ldflags.

Based on the link, it looks like you have everything in order to build DOSBox with custom library paths. In that case, you can add sdl sound 1.03, libogg, and lib vorbis to add support for compressed ogg tracks. Cheers.

Last edited by krcroft on 2019-01-07, 17:45. Edited 6 times in total.

Reply 59 of 145, by bam

User metadata
Rank Newbie
Rank
Newbie
krcroft wrote:

I personally found that when I uninstall sdl, sdl sound, sdl net, ogg, and vorbis libraries from my installed distro - and then perform custom builds of them each installed to a unique location, it can be tricky to get DOSBox configured to both see their headers and link with their libraries (typically needs a combination of cflags, ldflags, and ./configure arguments).

Ah.. Flatpak builds do not suffer such problems 😉