VOGONS

Common searches


Reply 100 of 145, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Kisai wrote:

That's a weird angle to take when you also integrate "more accurate FM synth"'s into your build. Saying "the user can't really tell" is not a good reason to reduce the quality on them. One should first make efforts to preserve the original media and data on them, then let the user decide if they want to save that space, don't make that decision for them. Internet bandwidth and disks are fast and large enough that you don't need to destroy your DOS games this way.

While regular HDDs with 1TB or even more are quite common, most people don't have SSDs with the same capacities yet, those with 256GB or 500GB are used much more. So, having games take up only 120-150 MB instead of 600-700 MB is definitely a nice thing if you have several of those installed, especially when you don't notice the difference between redbook audio or a high bandwidth OGG file.

About letting the user decide: Most regular users don't know jack about ripping CD audio, converting CD images, audio codecs, file bandwidths, editing cue files, etc. And they don't care, as well. Most just want to play games. Now, what if such a user decides he would prefer the smaller installation because he only has a smaller SSD? How would you, were you the publisher, handle this? Offer more download options, effectively increasing your infrastructure costs, for a probably small amount of users who actually know the difference?

GOG used to distribute the games with the full cd images (BIN + CUE) before, but switched to OGG audio some time later. IMHO the right decision, they distribute the games as convenient and efficiently packaged as possible. Leave preserving the full game discs to archiving services ike archive.org or institutions like the Video Game History Foundation. That's not the job of GOG or its customers.

If anyone feels the urge to use only full disc images for whatever reason, he can get them on archive,org, one of the many abandonware sites or just buy an original on Ebay instead of the download at GOG.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 101 of 145, by Kisai

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:

While regular HDDs with 1TB or even more are quite common, most people don't have SSDs...

Who said anything about SSD's? I don't even run dosbox off the SSD. You are trying to defend a company (GOG)'s intentionally degrading the games they are distributing, so they save money on bandwidth and then saying "go pirate the archival quality". Priorities please. In most cases the latter does not exist.

If I bought it on GOG, I want it to, reasonably play it, and sound like that machine from 1980-1996. CD Audio has a distinct stereo separation that is completely obliterated by using lossy compression on it. You can not claim "oh you won't miss it" if the user doesn't get to experience it to begin with.

Reply 102 of 145, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Kisai wrote:

Who said anything about SSD's? I don't even run dosbox off the SSD. You are trying to defend a company (GOG)'s intentionally degrading the games they are distributing, so they save money on bandwidth and then saying "go pirate the archival quality". Priorities please. In most cases the latter does not exist.

Just because you don't doesn't mean anyone else doesn't. Almost each and every PC nowadays is sold with a SSD, but seldom with more than 500GB. And don't forget that DOSBox isn't restricted to PCs only. Think about mobile phones, where even 64 Gbyte still isn't common. Or (modded) retro-consoles, some with with Raspberry Pis, which often come with only 16 or 32 GByte of SD card or even built in fixed storage. Heck, thanks to retroarch you can run DOSBox on a NES classic mini! 😀 Not everywhere you can run DOSBox you also have the storage capacity of a big HDD.

I get where you're coming from from an enthusiastic point of view. But still, I am defending their decision because it makes perfect sense from both a business point of view as well as the consumer one: Storage costs money. Real shitloads of money. While you, as consumer, can get a 1TB HDD for less than 200US$, a company which requires storage, maintenance, etc. has to pay around ten to 15 times as much for the same TB of storage. Not including the backups! So, as said company you can either sell your product at a considerably higher price, to compensate the expenditures, or you can strip features that most people don't need or care about to save storage capacity. What do you believe the customers would prefer? Can you imagine the outcry if GOG would raise the prices? So yes, the way GOG does is the way to go, IMHO.

Kisai wrote:

If I bought it on GOG, I want it to, reasonably play it, and sound like that machine from 1980-1996.

And does it honestly play or sound so much different with OGG music? Also keep in mind, as near as it gets, DOSBox is still no 100% accurate emulation of such hardware, so it will probably sound and look differently anyway.

Kisai wrote:

CD Audio has a distinct stereo separation that is completely obliterated by using lossy compression on it. You can not claim "oh you won't miss it" if the user doesn't get to experience it to begin with.

Apart from the fact most users don't exactly use audio hardware that would qualify as hi-fi with their DOSBox compatible gaming devices, OGG does a really good job on stereo separation, as you can read in the official documentation:

Lossless Stereo […]
Show full quote

Lossless Stereo

Using polar mapping and/or channel interleaving, it's possible to couple Vorbis channels losslessly, that is, construct a stereo coupling encoding that both saves space but also decodes bit-identically to dual stereo. OggEnc 1.0 and later uses this mode in all high-bitrate encoding.

Overall, this stereo mode is overkill; however, it offers a safe alternative to users concerned about the slightest possible degradation to the stereo image or archival quality audio.

...

Vorbis Stereo Modes

Vorbis, as of 1.0, uses lossless stereo and a number of mixed modes constructed out of lossless and point stereo. Phase stereo was used in the rc2 encoder, but is not currently used for simplicity's sake. It will likely be re-added to the stereo model in the future.

So, to conclude this: Unless you're not one of the very few people with extraordinary hearing and audio equipment most people on earth couldn't even afford, you wouldn't even notice the difference between high bandwidth OGG and real CD audio. So it makes sense for GOG and the users who just want to play games to sell/buy them with reencoded music to keep prices lower and storage capacities higher.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 103 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Kisai,

I transcode 39 GB of uncompressed BIN/CUE images to 2.7 GB using Ogg Opus at varying data rates, which I play on my Raspberry Pi.

At the time, I paid close to $1/GB for SanDisk's highest-spec'd 128GB card and it was one of the largest available, so I have a very real interest in maximizing both the audio quality and how much I can fit on the storage. Opus does both. It achieves transparency at 96 kbit/s, and that's considering most ABX testing is done by very skilled listeners using modern high-end audio equipment (which is certainly beyond what I'm using at home and possibly higher fidelity than the circa-90s hardware used to author the original audio tracks!)

I'm also an archivist at heart: I retain the original images on my server along with checksums, forward-error correction data, and FLAC encodings of their CDDA tracks. Both of my use-cases (Raspberry Pi + Desktop) drove me to author this audio patch.

Regarding your statement that "CD Audio has a distinct stereo separation that is completely obliterated by using lossy compression", like Yesterplay mentions, if you have such amazing hearing I suggest you head over to the Hydrogen Audio forums and lend your golden ears to their ABX testing efforts, and refer us to your results.

As for the suggestion that the patch be modified to include a warning to users of lossy-encoded CDDA tracks:

  • Does your car-stereo display a visual warning when it plays AAC/MP3 content?
  • Do the iTunes and YouTube apps warn users to find lossless sources instead of playing their lossy content? (given both sources stream in either AAC or Opus)
  • Do BlueTooth headsets come with consumer-warning stickers that the SBC audio codec used to relay audio is lossy?
  • Does your HDTV warn you that the 2D pixel fidelity is undoubtedly compromised versus the source material given all content feeding an HDTV originates in lossy-format? (Uncompressed 24bit 1080p 60Hz has a data-rate of 370MB/s, which means two hours of content would soak up 2.7TB of disk space, and you would need four Gigabit Ethernet connections each running near peak rates to feed your TV. Oh, and you'd need a RAID of HDDs to maintain those speeds too.. unless you opted to store your lossless video content on huge 4TB SSDs, which are certainly fast enough but cost $600 USD/ea. Instead, even the highest fidelity of 1080p movies are lossy-compressed down to ~25GB which throws away 99.07% of data.. more than 10-fold the discard-rate versus lossy audio compression)

/<ok.. enough snark 🤣 >

But more seriously, like Yesterplay mentioned - either someone is savvy enough to rip their DOS RedBook tracks (in which case they will have very real reasons for their choice in codec) or they're merely a casual consumer of fixed content (in which case they have zero say either way over the codec or how it was produced). In both cases, nagging them to find a lossless source is not helpful.

Edit: regarding companies selling DOS games, if some form of this patch is eventually merged, then I would hope those companies would revise their releases across-the-board by replacing their Vorbis and MP3 track with either FLAC and/or Opus, as these two are leaders in their respective camps.

Reply 104 of 145, by dreamer_

User metadata
Rank Member
Rank
Member

This is anecdotal evidence, but just to show that there are other POVs here: I don't have such good hearing and can't really tell the difference between mp3, ogg, opus and flac - I am annoyed when companies release DOS games with CD image of uncompressed audio (this usually indicates low-effort release that was not tested at all before being sold). The small game download turns into a huge one, and I need to wait for it before testing (due to the nature of my project, I juggle a lot of game installations at the time).

From what I've seen over last few months, almost all game releases use music tracks in .ogg format (very often incorrectly marked with MP3 type in a .cue file). TR1 is the only release I own where publisher submitted mp3s.

Having a warning (and only a warning) focusing on mp3 specifically makes more sense to me. Also, a warning (and only a warning) issued when file extension does not match file type in .cue might be nice. Both are rather low priority though.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 105 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

dreamer, yeah, when the bitrate is tailored for both the codec being used and the audio source's complexity, the resulting encoded stream should be essentially transparent to the majority of listeners. So in that regard, I think your experience is the norm. (Take youTube, Amazon, and iTunes.. it's been a long time since I've heard people complaint about compression artifacts; besides unreasonable audiophiles inspecting spectral graphs pointing out dB differences).

kisai, I think the quality and stereo loss you're referring to is when pirate groups deliberate pre-process the media content in ways to maximize its lossy compressibility. So for example, 24-bit raster PNG textures can have their bit-depth and resolution cut in half and then compressed with jpeg for a 50-fold space savings. 44.1KHz stereo WAVs can be reduced to 32 KHz and mono, and saved as 64 kbit/s MP3 for a similar reduction. Both methods introduce significant and detectable artifacts, but I suppose back in the day reducing bandwidth and storage were a priority.

Reply 106 of 145, by Kisai

User metadata
Rank Member
Rank
Member
krcroft wrote:

dreamer, yeah, when the bitrate is tailored for both the codec being used and the audio source's complexity, the resulting encoded stream should be essentially transparent to the majority of listeners. So in that regard, I think your experience is the norm. (Take youTube, Amazon, and iTunes.. it's been a long time since I've heard people complaint about compression artifacts; besides unreasonable audiophiles inspecting spectral graphs pointing out dB differences).

kisai, I think the quality and stereo loss you're referring to is when pirate groups deliberate pre-process the media content in ways to maximize its lossy compressibility. So for example, 24-bit raster PNG textures can have their bit-depth and resolution cut in half and then compressed with jpeg for a 50-fold space savings. 44.1KHz stereo WAVs can be reduced to 32 KHz and mono, and saved as 64 kbit/s MP3 for a similar reduction. Both methods introduce significant and detectable artifacts, but I suppose back in the day reducing bandwidth and storage were a priority.

I had friends who were into "the scene" in the 90's and there was a lot bizarre ways pirates would make things smaller, but most of the time it was excising the speech first, music second (so you only had the option of the OPL2 music.) Then as 3D stuff started to come out, they would also convert 32-bit textures to 15/16-bit textures. "Nobody is going to notice, and if they do, they can buy the game instead"

Now 20 years later there IS no option to buy the unadulterated game anymore except by looking on eBay, and even then you get counterfeits made from pirate rips. So pardon me if I think the games should, at worst, come with the FLAC tracks if the CPU is power powerful enough to decode it, otherwise come with the original disc image. If you want to compress it yourself so it can fit on a Nintendo Wii, by all means, that's not the reason I chimed in.

As for warning the user, it's even more silly to compare that to a car stereo mp3 player, when it says "mp3 player" on the stereo. There is no surprise.

And yes, I can absolutely tell when something has been lossy-compressed. It doesn't drive me up the wall, but the warble heard in mp3's makes me wonder why people don't notice. I've not heard enough Opus content to make a judgement call. Again, this is not a call to annoy people, it's to draw attention to the fact that the game has "CD audio" tracks that are not CD quality.

Reply 107 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

If you can rip some of your own CDs to WAV, download the lame and opus command line encoders from the first post in this thread. For Opus, use a bitrate of 96 and for lame use: lame -V2 sample.wav sample.mp3, which averages around 190kbits/s. Then use ABX software and see if you can statistically tell the difference between the encodings and the WAVs. Honestly; give it a chance, because these should be undetectable from their lossless counterpart.

Yeah, hopefully in the coming years many of those early 2000s windows games will fall under archive and research exemptions similar to DOS games today, and archive.org can start hosting the original DVD media. With today's games being fragmented into thin "rendering" clients fed by server-side logic and media, I fear an unarchiveable form of dark ages will come for these types of games. Thankfully I don't have a personal interest in them but might be a dilemma for today's younger generations.

I also agree that GOG and Steam should offer buyers the right to additionally download original media images.. similar to FLAC being an option for most music purchases. After all, the company still needs to store these images somewhere, so there's little extra cost involved (GOG only sells a thin fraction of DOS titles, and we know from eXo the aggregate weights in around 500GB).

Reply 108 of 145, by pantercat

User metadata
Rank Newbie
Rank
Newbie
dreamer_ wrote:

Hm, I couldn't make it to compile on Linux with GCC 9.2 (it was an error in dr_flac 0.12.0, which seems to be an unreleased version?) - but patch v9 applied cleanly on top of trunk@4258, so I am using it for the time being.

Hi, I think I've same or similar issue.

I've tried to compile DOSBox SVN r4267 without success. I've compiled previous versions of this patch with no issues, ie: "DOSBox ECE r4257 (Linux source).7z"

I'm using Debian testing and "gcc -v" returns "gcc version 9.2.1 20190909 (Debian 9.2.1-8)".

$ patch -p1 < dosbox_r4258-cdda_audio_updates-rev11.patch && ./autogen.sh && ./configure && make
(...)
In file included from flac.c:46:
dr_flac.h: In function ‘drflac_read_pcm_frames_s16__decode_left_side__sse2’:
dr_flac.h:8243:60: warning: implicit declaration of function ‘drflac__mm_packs_interleaved_epi32’ [-Wimplicit-function-declaration]
8243 | _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dr_flac.h:8243:60: error: incompatible type for argument 2 of ‘_mm_storeu_si128’
8243 | _mm_storeu_si128((__m128i*)(pOutputSamples + i*8), drflac__mm_packs_interleaved_epi32(left, right));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| int
In file included from dr_flac.h:1052,
from flac.c:46:
/usr/lib/gcc/x86_64-linux-gnu/9/include/emmintrin.h:725:43: note: expected ‘__m128i’ {aka ‘__vector(2) long long int’} but argument is of type ‘int’
725 | _mm_storeu_si128 (__m128i_u *__P, __m128i __B)
| ~~~~~~~~^~~
(...)

Thanks for your time and keep up the good work.

Reply 109 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
pantercat wrote:
dreamer_ wrote:

Hm, I couldn't make it to compile on Linux with GCC 9.2 (it was an error in dr_flac 0.12.0, which seems to be an unreleased version?) - but patch v9 applied cleanly on top of trunk@4258, so I am using it for the time being.

Hi, I think I've same or similar issue.

Thanks pantercat!

Sorry you've hit this; I haven't posted a new diff yet, but I'm chasing a big-endian WAV decode issue (https://github.com/mackron/dr_libs/issues/66) first before I post the next revision.

Feel free to grab the latest stable source here, which has this fixed plus a handful more minor updates - https://github.com/dreamer/dosbox-staging/tre … oft/cdda/master

Reply 110 of 145, by pantercat

User metadata
Rank Newbie
Rank
Newbie

Hi krcroft, I'm happy to see this have already been fixed. I've just downloaded latest dosbox-staging source and I can confirm compilation ends cleanly 😀

Thank you very much and happy coding 😀

Reply 111 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Revision 12 is posted.

Changes:

  • The patch now makes use of the single-header dr_wav codec, replacing the prior SDL_Sound1.2-base WAV codec
  • big-endian architectures, such as PowerPC and Sun Sparc, are supported and tested for all codecs. Top-notch work by Dave Mackron addressing a WAV decode issue on big-endian hardware (https://github.com/mackron/dr_libs/issues/66)
  • Sony Wave64 (.w64) tracks are now supported, as these are now handled by dr_wav
  • The code is now hosted under a dosbox-staging branch (krcroft/cdda/master) and being fed through dreamer's growing GitHub workflow! The workflow sends every change through a battery of Linux, OS X, and Windows compilers and finishes with static-code analysis, which revealed issues that are addressed in this patch. This branch can be found here: https://github.com/dreamer/dosbox-staging/tre … oft/cdda/master

Enjoy the music!

Last edited by krcroft on 2019-10-05, 13:58. Edited 4 times in total.

Reply 112 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
pantercat wrote:

Hi krcroft, I'm happy to see this have already been fixed. I've just downloaded latest dosbox-staging source and I can confirm compilation ends cleanly 😀

Thanks for the confirmation!

Reply 113 of 145, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I tried to apply the patch o the ECE source but ran into the following error. Do you have any idea what might cause it?

make[4]: Leaving directory `/home/miche/dosbox/src/libs/gui_tk'
Making all in decoders
make[4]: Entering directory `/home/miche/dosbox/src/libs/decoders'
make[4]: *** No rule to make target `all'. Stop.
make[4]: Leaving directory `/home/miche/dosbox/src/libs/decoders'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/miche/dosbox/src/libs'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/miche/dosbox/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/miche/dosbox'
make: *** [all] Error 2

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 114 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

what might be happening is there could be old or prior files/directories. Try your source in a fresh top level dosobox directory in which its never been compiled, then do the usual (appy patches, autogen, configure, make).

Alternatively, delete all the .deps directories and then configure again. From your top-level dosbox source dir:
$ find . -type d -name '.deps' | xargs rm -rf
$ ./configure
$ make -j $(nproc)

Hopefully either does the trick.

Reply 115 of 145, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
krcroft wrote:

Hopefully either does the trick.

Neither did, I'm afraid. I check out a fresh copy every time I compile a new build, anyway, so that shouldn't be the problem. And deleting the .deps files didn't work either. I tried the previous patch again to make sure my it's not my mingw/msys installation that's messed up, this time it worked just fine again. Maybe because I don't use dosbox-staging as source but still the SVN?

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 116 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

I check out a fresh copy every time I compile a new build, anyway, so that shouldn't be the problem. And deleting the .deps files didn't work either. I tried the previous patch again to make sure my it's not my mingw/msys installation that's messed up, this time it worked just fine again. Maybe because I don't use dosbox-staging as source but still the SVN?

Sorry Yesterplay80, and thanks for the flagging this! Indeed; I generated a clean diff against the latest SVN pull and the build runs clean.
Rev13 is now posted, which also includes the updated dr_* codecs released as of 12 hours ago (and tested on my machine).

Reply 117 of 145, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Still, something seems to be not quite right with your patch. It won't apply here, also and probably because it tries to change a lot more files than the previous ones (see first picture) and even undoes changes introduced before, for example in SVN r4266. Changes that have nothing to do with audio at all (see second picture). 😕 Or am I using it wrong?

patch 1.JPG
Filename
patch 1.JPG
File size
816.08 KiB
Views
1803 views
File license
Fair use/fair dealing exception
patch 2.JPG
Filename
patch 2.JPG
File size
91.24 KiB
Views
1803 views
File license
Fair use/fair dealing exception

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 118 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Argh; looks like my master branch has fallen behind in my SVN repo, and thus the diff against a fresh download of the dosbox source then attempted to revert any differences.

I'm focusing on using dosbox-staging as my baseline going forward, and it was used to create the rev12 diff but the patch generation had issues too (likely something I didn't do right in the diff). I will dig in tomorrow and sort it out.

I might try to move toward providing a link to githubs branch differencing tool that uses git to generate the diff on the fly. That will eliminate much of the manual steps I've previously needed to do to prepare a patch (and can be a source of human error)

Reply 119 of 145, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Yesterplay,

Ok, round two (or is it three? 😀 )

$ diff -x gui_tk -x zmbv -x '.git*' -x scripts -Naur trunk dosbox_audio_updates > dosbox_r4267-cdda_audio_updates-rev13_2.patch
$ zopfli -i150 dosbox_r4267-cdda_audio_updates-rev13_2.patch
$ ls -1l dosbox_r4267-cdda_audio_updates-rev13_2.patch.gz

-rw-r--r-- 1 kcroft users 376755 Oct 7 16:38 dosbox_r4267-cdda_audio_updates-rev13_2.patch.gz

The patch is looking as expected now:

$ grep '+++' dosbox_r4267-cdda_audio_updates-rev13_2.patch | cut -f1 -d$'\t'

+++ dosbox_audio_updates/configure.ac
+++ dosbox_audio_updates/Makefile.am
+++ dosbox_audio_updates/src/dos/cdrom.h
+++ dosbox_audio_updates/src/dos/cdrom_image.cpp
+++ dosbox_audio_updates/src/dos/drive_iso.cpp
+++ dosbox_audio_updates/src/libs/decoders/archive.h
+++ dosbox_audio_updates/src/libs/decoders/audio_convert.c
+++ dosbox_audio_updates/src/libs/decoders/docs/copying.txt
+++ dosbox_audio_updates/src/libs/decoders/docs/credits.txt
+++ dosbox_audio_updates/src/libs/decoders/docs/license.txt
+++ dosbox_audio_updates/src/libs/decoders/dr_flac.h
+++ dosbox_audio_updates/src/libs/decoders/dr_mp3.h
+++ dosbox_audio_updates/src/libs/decoders/dr_wav.h
+++ dosbox_audio_updates/src/libs/decoders/flac.c
+++ dosbox_audio_updates/src/libs/decoders/internal/Makefile
+++ dosbox_audio_updates/src/libs/decoders/Makefile.am
+++ dosbox_audio_updates/src/libs/decoders/mp3.cpp
+++ dosbox_audio_updates/src/libs/decoders/mp3_seek_table.cpp
+++ dosbox_audio_updates/src/libs/decoders/mp3_seek_table.h
+++ dosbox_audio_updates/src/libs/decoders/opus.c
+++ dosbox_audio_updates/src/libs/decoders/SDL_sound.c
+++ dosbox_audio_updates/src/libs/decoders/SDL_sound.h
+++ dosbox_audio_updates/src/libs/decoders/SDL_sound_internal.h
+++ dosbox_audio_updates/src/libs/decoders/stb.h
+++ dosbox_audio_updates/src/libs/decoders/stb_vorbis.h
+++ dosbox_audio_updates/src/libs/decoders/stb_vorbis_test.c
+++ dosbox_audio_updates/src/libs/decoders/vorbis.c
+++ dosbox_audio_updates/src/libs/decoders/wav.c
+++ dosbox_audio_updates/src/libs/decoders/xxh3.h
+++ dosbox_audio_updates/src/libs/decoders/xxhash.c
+++ dosbox_audio_updates/src/libs/decoders/xxhash.h
+++ dosbox_audio_updates/src/libs/Makefile.am
+++ dosbox_audio_updates/src/Makefile.am
+++ dosbox_audio_updates/VERSION

Patching against the dosbox snapshot ...

$ curl http://source.dosbox.com/dosboxsvn.tgz | tar zx
$ cd dosbox
$ zcat ~/Download/dosbox_r4267-cdda_audio_updates-rev13_2.patch.gz | patch -p1

patching file configure.ac
patching file Makefile.am
patching file src/dos/cdrom.h
patching file src/dos/cdrom_image.cpp
patching file src/dos/drive_iso.cpp
patching file src/libs/decoders/archive.h
patching file src/libs/decoders/audio_convert.c
patching file src/libs/decoders/docs/copying.txt
patching file src/libs/decoders/docs/credits.txt
patching file src/libs/decoders/docs/license.txt
patching file src/libs/decoders/dr_flac.h
patching file src/libs/decoders/dr_mp3.h
patching file src/libs/decoders/dr_wav.h
patching file src/libs/decoders/flac.c
patching file src/libs/decoders/internal/Makefile
patching file src/libs/decoders/Makefile.am
patching file src/libs/decoders/mp3.cpp
patching file src/libs/decoders/mp3_seek_table.cpp
patching file src/libs/decoders/mp3_seek_table.h
patching file src/libs/decoders/opus.c
patching file src/libs/decoders/SDL_sound.c
patching file src/libs/decoders/SDL_sound.h
patching file src/libs/decoders/SDL_sound_internal.h
patching file src/libs/decoders/stb.h
patching file src/libs/decoders/stb_vorbis.h
patching file src/libs/decoders/stb_vorbis_test.c
patching file src/libs/decoders/vorbis.c
patching file src/libs/decoders/wav.c
patching file src/libs/decoders/xxh3.h
patching file src/libs/decoders/xxhash.c
patching file src/libs/decoders/xxhash.h
patching file src/libs/Makefile.am
patching file src/Makefile.am
patching file VERSION

And builds clean..

$ ./autogen.sh && ./configure && make -j$(nproc)
...
g++ -Ofast -ffast-math -march=native -frename-registers -ffunction-sections -fdata-sections -fomit-frame-pointer -flto=8 -pipe -mno-ms-bitfields -Ofast -ffast-math -march=native -frename-registers -ffunction-sections -fdata-sections -fomit-frame-pointer -flto=8 -pipe -o dosbox dosbox.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/mame/libmame.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a libs/decoders/libdecoders.a libs/decoders/internal/lib/libopusfile.a libs/decoders/internal/lib/libspeexdsp.a libs/decoders/internal/lib/libopus.a libs/decoders/internal/lib/libogg.a -lasound -lm -ldl -lpthread -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lSDL -lpthread -lpng -lz -lSDL_net -lX11 -lGL
make[3]: Leaving directory '/ssd_backup/src/dosbox/src'
make[2]: Leaving directory '/ssd_backup/src/dosbox/src'
...
make[1]: Leaving directory '/usr/src/dosbox'

$ ls -1l src/dosbox
-rwxr-xr-x 1 kcroft users 4466232 Oct 7 16:41 src/dosbox

If it works for you, I'll promote it to the original post; thanks again for the checks and reports!

Attachments