Hi, not yet
but i did update the default gcc to 7
the remark is that cc1plus is NOT to be found, but i have no clue were to find it, since afai understand, it should be Part off the distribution.
this its with the extra 'include' command, but no cc1plus is no cc1plus. 'bliep'
cri@linux-3le6:~/Downloads/pcmenc> gcc pcmenc2.cpp resample.c -std=gnu++11 -o pcmenc2 -O2 -Wall
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
cc1: warning: command line option ‘-std=gnu++11’ is valid for C++/ObjC++ but not for C
In file included from resample.c:56:0:
st.h:25:9: error: unknown type name ‘uint32_t’
typedef uint32_t st_size_t;
^~~~~~~~
st.h:27:9: error: unknown type name ‘uint32_t’
typedef uint32_t st_rate_t;
^~~~~~~~
resample.c: In function ‘st_resample_start’:
resample.c:251:21: error: ‘uint32_t’ undeclared (first use in this function); did you mean ‘u_int32_t’?
r->Xsize = (uint32_t)(2*Xoff + i/(1.0+r->Factor));
^~~~~~~~
u_int32_t
resample.c:251:21: note: each undeclared identifier is reported only once for each function it appears in
cri@linux-3le6:~/Downloads/pcmenc> gcc --version
gcc (SUSE Linux) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
cri@linux-3le6:~/Downloads/pcmenc> sudo zypper in cc1plus
[sudo] password for root:
Loading repository data...
Reading installed packages...
'cc1plus' not found in package names. Trying capabilities.
No provider of 'cc1plus' found.
Resolving package dependencies...
Nothing to do.
cri@linux-3le6:~/Downloads/pcmenc>
Shouldn't you write g++ instead of gcc for C++ programs?
Thats a bit confusing to me, there are so many 'roads to rome'
eg https://stackoverflow.com/questions/42979055/should-i-use-c-...
this is mentioned in the error, so maybe i should include sys/sys/types.h for the correct link, AND ... it does not work
what is the original compiler for which pcmenc.cpp is written, and which version??
i always have those extra mountains to pass by just to climb a hill.
i tried : opensuse leap 15, leap 42.3, lubunt16
cpp-g++ 5 and 7
i did update-alternatives on all 3 systems
çomputer says ú_32'
The crash mentioned above is caused by memory/heap corruption in st_resample_flow. In a nutshell, the input file has 1024 samples, but the loop in st_resample_flow computes Xsize to be 4465 so the code walks off the end of the sample buffer (ibuf).
A naive fix to prevent crashes is to limit the loop by the actual number of input samples.
>diff ..\..\pcmenc.cpp pcmenc.cpp 161c161 < int rv = st_resample_flow(effp, ibuf + iLen, obuf + oLen, &idone, &odone); --- > int rv = st_resample_flow(effp, ibuf + iLen, inLen - iLen, obuf + oLen, &idone, &odone); >diff ..\..\resample.c resample.c 268c268 < int st_resample_flow(eff_t effp, st_sample_t *ibuf, st_sample_t *obuf, --- > int st_resample_flow(eff_t effp, st_sample_t *ibuf, long cbuf, st_sample_t *obuf, 297c297 < for(i = r->Xread; i < Nx + r->Xread ; i++) --- > for(i = r->Xread; i < Nx + r->Xread && i < cbuf; i++) 396c396 < rc = st_resample_flow(effp, NULL, Obuf, (st_size_t *)&Isamp, (st_size_t *)&Osamp); --- > rc = st_resample_flow(effp, NULL, 0, Obuf, (st_size_t *)&Isamp, (st_size_t *)&Osamp); >diff ..\..\st.h st.h 86c86 < int (*flow)(eff_t effp, st_sample_t *ibuf, st_sample_t *obuf, --- > int (*flow)(eff_t effp, st_sample_t *ibuf, long cbuf, st_sample_t *obuf, 116c116 < int st_resample_flow(eff_t effp, st_sample_t *ibuf, st_sample_t *obuf, --- > int st_resample_flow(eff_t effp, st_sample_t *ibuf, long cbuf, st_sample_t *obuf,
Whether this results in valid output is a separate question. But it does fix the crash.
I should note that in general, this code has a number of alignment issues that may or may not cause crashes depending on the CPU and OS. I didn't spend time addressing them, but a couple jumped out at me: calloc params in wrong order, and using a char buffer to host structure (st_effect) which contains larger fields.
Hi,
you mention that you DO compile. On what system and with what compiler?
meanwhile i did manage to compile by a rude trick:
i changed u32int_t to u_32int_t on 5 locations and now the compilation works out a 38kb file which can NOT digest the wave file.
ch@linux-6n36:~/Desktop/some-zx/dutchvox/Vp_4p4_work> ./pcmenc2 -p 0 -cpuf 3546900 -dt1 97 -dt2 97 -dt3 175 -a 115 -rto 1 -c 2 -i 2 54321_short.wav Encoding PSG samples at 9612Hz Only supports 8, 16, 24, and 32 bits per sample Failed to load wav file: 54321_short.wav
Then i realized you made that length change AND you did (re)compile, but that gives a load of new errors.
I promissed not to spoil this tread with error codes, hmmmmm
i keep trying , gxx, g++ gcc Wgcc, i will find one
if this is not mentioned already: I think to run correctly on 64bit machines the typedefs at the top (in pcmenc.cpp) need to be changed to:
typedef unsigned char UInt8; typedef unsigned short UInt16; typedef unsigned int UInt32; typedef signed char Int8; typedef signed short Int16; typedef signed int Int32;
(so long -> int as long is nowadays typically 64bit)
(the fail to load wav error will otherwise result)
I managed to compile and convert short clips (had to mangle the assembler to get it to assemble with glass)..I think to make roms bigger than 32kb is not possible with the provided code?
if this is not mentioned already: I think to run correctly on 64bit machines the typedefs at the top (in pcmenc.cpp) need to be changed to:
typedef unsigned char UInt8; typedef unsigned short UInt16; typedef unsigned int UInt32; typedef signed char Int8; typedef signed short Int16; typedef signed int Int32;
(so long -> int as long is nowadays typically 64bit)
(the fail to load wav error will otherwise result)
I managed to compile and convert short clips (had to mangle the assembler to get it to assemble with glass)..I think to make roms bigger than 32kb is not possible with the provided code?
Hi
It did not help, yet. did you compile in https://esolangs.org/wiki/Glass ? this many steps awy from my path.
but you managed to compile, with g++ ??
Summarize of arguments:
IIRC the current version has been compiled under windows XP and it should be compatible with GCC
The crash mentioned above is caused by memory/heap corruption in st_resample_flow. In a nutshell, the input file has 1024 samples, but the loop in st_resample_flow computes Xsize to be 4465 so the code walks off the end of the sample buffer (ibuf).
#include < cstdint > on recent g++ (9.2.1) to compile
use g++ for c++
change typedef 'long' to 'int' fir 64bit
and i TRIEd to change by error-suggestion:
In file included from pcmenc2.cpp:118:0:
st.h:25:9: error: ‘uint32_t’ does not name a type; did you mean ‘u_int32_t’?
typedef uint32_t st_size_t;
^~~~~~~~
u_int32_t
i changed
UInt32_t to U_Int32_t
glass is https://bitbucket.org/grauw/glass, to be used to generate the msx rom or com (once you have the bin after running pcmenc)!
I compiled with g++ - recent and older ones (back to 4.5) should work..
If you still get the "Failed to load wav file: 54321_short.wav", and you changed to two longs in the typedef to int I would check
the wav file (it may be that its of a format that is not supported..)...you can debug this by inserting printf statements in the
pcmenc loadSamples function printing out the success variable and see when it becomes zero...that may give you a hint..
Where can I find the latest version of pcmenc?
The one on MRC seems quite old.
that is the last one
Thank for the information... and for this very intresting tool. 