soroushzargar
commented
5 years ago @soroushzargar perhaps you could do this.. it would be better if the reconstruction-test were easier to run. For example, have a script that downloads and suitably formats the appropriate data and then runs the test. Right now there is some hacky stuff going on with a
tempdir that probably isn't in the source tarball.
Ok I think a better way is that the file itself should be a runnable file with passing arguments; something like
`./reconstruction-test --dataset-dir
arguments passed by should be
--dataset-dir: An address to a dataset directory which includes some.wavfiles.--sample-rate: The sample rate in which the comparison is supposed to work with.--release-df: If this flag is appeared, then the procedure will create a set of pandas dataframes saved in.csvformat which could be used with pandas later.--release-logIt prints out a tab delimited log file which will show the output of comparison.
This will shorten the code and also reduces dependancies.
I was only printing out the bits in the file as a debugging step. But I think we should be displaying the file sizes or bits per unit time in some form alongside the various compression methods; this will make comparisons more meaningful.
The output of the file can be in following shape
Results on sampling rate = <sampling rate>
<Filename> <algorithm> <bitrate> <psnr> [repeating for each compression algorithm]I just set the bits per sample to 6 in reconstruction-test.py
By that you mean 16? Sorry here I just got confused.
but we may want to test various settings. What I would really like is some info about PSNR's and file sizes formatted in a way that's easily readable.
Did I cover that in previous part?
IMO a simple Python program that prints out a summary would be preferable to this CSV stuff, in that it would be clearer. But as long as you do print out something readable at some point (maybe as a post processing step that might be in a separate script) it's OK with me. Make sure it's all documented with a top-level run.sh or something.
Ok I think a top level .sh with man documentation is what you want here. Right?
danpovey
@soroushzargar perhaps you could do this.. it would be better if the reconstruction-test were easier to run. For example, have a script that downloads and suitably formats the appropriate data and then runs the test. Right now there is some hacky stuff going on with a
tempdir that probably isn't in the source tarball.I was only printing out the bits in the file as a debugging step. But I think we should be displaying the file sizes or bits per unit time in some form alongside the various compression methods; this will make comparisons more meaningful.
I just set the bits per sample to 6 in reconstruction-test.py but we may want to test various settings. What I would really like is some info about PSNR's and file sizes formatted in a way that's easily readable. IMO a simple Python program that prints out a summary would be preferable to this CSV stuff, in that it would be clearer. But as long as you do print out something readable at some point (maybe as a post processing step that might be in a separate script) it's OK with me. Make sure it's all documented with a top-level run.sh or something.