Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test files are not in release tarballs #53

Open
davexunit opened this issue Mar 1, 2016 · 6 comments
Open

Test files are not in release tarballs #53

davexunit opened this issue Mar 1, 2016 · 6 comments

Comments

@davexunit
Copy link

Running make check in the source tree extracted from the 0.2.0 release tarball yields this:

mkdir -p libdcadec
gcc  -o test/stddev -O2 -Wall -Wextra test/stddev.c -lm
cd test && ./test.sh
ERROR: Run 'git submodule update --init test/samples' first.
Makefile:161: recipe for target 'check' failed

It would be great if the release tarballs included the missing files from the Git submodule so that users can run the test suite before installing. Thanks!

@TimothyGu
Copy link
Contributor

The test samples are kind of big, so it wouldn't be practical to include them…

@f2404
Copy link
Contributor

f2404 commented Mar 1, 2016

Maybe release a separate package containing the samples?

@MarcusJohnson91
Copy link

@TimothyGu Really? they're 2mbs...

and if that's STILL too big, use DCACut to cut out a single frame of each sample, and get rid of the WAV originals and just store their hash...

(preferably both their MD5 and SHA256 in the extremely unlikely case of collusions.)

Edit: I just zipped the untouched DTS samples and it only took up 437kb... (using OS X's default compression settings)

@TimothyGu
Copy link
Contributor

Using a hash sounds good. It is not big big, but 437kB is almost twice the size of the source tarball 220kB.

@MarcusJohnson91
Copy link

That's a good point, we should try slimming it down.

I just went through xll_71_24_96_768.dtshd (which is 54 kb) and scanned for XLL and ExSS magic numbers, and there are 7 of them, so I mean it wouldn't be crazy to cut it down to just one frame, which should drop the file size to roughly 8KB or so...

@MarcusJohnson91
Copy link

It's actually kinda strange because there are 7 frames for 4096 samples, which would be one frame at best, 4 at worst in LBR...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants