john32b / cdcrush.net Goto Github PK

Currently, progress reporting on the progress bar is based on number of tasks completed / total tasks.
Some tasks can take a while to finish, and also there are more than one task running at the same time,
I need to think of a better way to implement this,

• More than one progress bar?
• Estimated Time ?
• Calculate the progress of each task and calculate that into the main progress so it's smoother ?

This is really a suggestion, not an issue, however it may be worth looking at TAK audio in addition to FLAC for lossless audio, as it allows for even better lossless compression than FLAC. There's a CLI version of the compressor available, so parameters should be able to be passed in using a similar method as the other supported codecs are. Here's some information about TAK if you're not familiar with it: https://wiki.hydrogenaud.io/index.php?title=TAK

This might be better than a a few-size-fits-all approach. You're already using ffmpeg to convert, so it would be cool if the program just generated a text string that got passed to ffmpeg. It would expose commands like this and allow for user editing.

Some video compression tools already use this approach. It is great for power users, because they can customize the command as much as they want. It also gives the tool more forward-compatibility.

It would be even better if the tool loaded options from a config file for the ffmpeg path. Something like:

[option-flac]
command: ffmpeg -i %1 %1.flac
[option-ogg]
command: ffmpeg -i %1 %1.ogg

Then I could add Opus recipes at different bitrates, for example. :)

Since FFMpeg is included with the program (at least with the full copy of it) the default path of ffmpeg.exe should match the folder where the file is put by default. This may make it a little easier for end-users that aren't savvy enough to know where the executable is dropped and will make the program immediately usable right out out of the gates for users who download the full version.

add 7z
because for example retroarh, it allows you to open 7z on the fly, without arms (removal / unpacking)

Several images in one archive
This is very effective if there are several little different images - translations, hacks.
In this case, solid archive 7z, lrzip is used.

And I Can't extend size so I Can't use This Tool. Please fix this bug. Thanks.

After compressing/restoring produce a full report of the cd and tracks with info like:
trackLength, sectorSize, md5, pregaps, filesizes, etc

That info would be

• stored to a file?
• displayed in a window?

Purpose is to be able to confirm/check CD checksums and infos against online databases like http://redump.org/

I chose FreeArc for compressing the archives a few years ago for the npm version of cdcrush, it is an open source archiver and it provided good and fast compression.

However It seems that it's inactive for a long time and the project's homepage is down http://freearc.org. The latest free arc version 0.666 , can't be found from officially anywhere online, neither does the source code.

So I'm going to drop freearc for compressing but not entirely, I'm going to keep it for backwards compatibility, so old archives can still be extracted.

As for what I'm going to be replacing freearc with, I'm guessing 7-zip since it's open source, well documented and supported.

It's coming in the next version. Audio Tracks can be stored and restored to an exact byte for byte copy of the original file.

Opus is a modern audio codec with better compression at the same apparent audio quality. 96kbps fared well in HydrogenAudio (audio enthusiast community) tests.

https://www.opus-codec.org/

It's built into ffmpeg as well.

The initial nodejs version of cdcrush supported batch operations. You could just call cdcrush *.arc and it would restore all CD archives.

The code engine is almost ready for this, the only thing I need to do is the user interface part, which is something that I need to figure out.

WILL implement at a later version, as it's very helpful.