pipian / libcueify Goto Github PK
View Code? Open in Web Editor NEWCross-platform library for extracting audio CD metadata (TOC, CD-Text, etc.) and formatting cuesheets
License: MIT License
Cross-platform library for extracting audio CD metadata (TOC, CD-Text, etc.) and formatting cuesheets
License: MIT License
EAC has several index detection modes. It may be necessary to detect indices in different ways.
Case study: Sounds of Earth/Voyager Golden Record.
Once OS-specific modularity is implemented, we can start implementing functions using different operating systems. Mac OS X/Darwin is one such target.
Although the cueify example has done a good job exercising the APIs and doing basic debugging, we need a proper set of unit tests to ensure that all APIs work as expected (especially serialization/deserialization).
cueify is nice and all, but this library should also read and write textual cuesheet files as well.
To maximize usability of this library, SWIG bindings should be added. Ideally, these bindings should target (minimally) Perl, Python, and Ruby.
Might be nice to actually calculate discids of TOCs on the side. That would let this basically almost entirely supplant libdiscid (except with a different API).
Refactor API in /include.
Investigate the possibility of extracting (or at least detecting) karaoke (CD-G) data and adding it to libcueify.
Solaris support is needed to allow libcueify to act as a complete replacement for the unportable code in the trunk repo of libdiscid.
In reviewing the win32 APIs being ported and cueify's old code, I noted the use of ReadRawSector to properly detect the mode of data in a data track. An API should be added to handle this properly like with the other APIs (it need not support ReadRawSector's functionality in its entirety, just the mode-detection part).
As part of the refactoring of the API, the code should make OS-specific APIs separate from the external APIs (c.f. libdiscid)
IOCTL_SCSI_GET_ADDRESS does not work with USB drives. Catching error 50 (ERROR_NOT_SUPPORTED) should be sufficient if LUNs can be ignored.
Not always possible, but when possible, we need to be able to detect when parts of the advanced API (e.g. read_full_toc APIs) are unsupported on a platform.
Major API change (in terms of the include paths; not in terms of the API names), but no one is using the library yet, so we can afford to do this.
Once the refactoring of the codebase is complete, cueify (in /examples) should be rewritten to use the API.
OpenBSD support is needed to allow libcueify to act as a complete replacement for the unportable code in the trunk repo of libdiscid.
Right now, although the old code was written for win32 (well, Windows XP and above), no testing is happening using the platform, and it almost certainly does not compile on win32 at this time. If we're keeping the code, we should make it work.
Track control flags now work correctly, but have not been added to the cueify example program.
The API should be well-documented with Doxygen. This is already (sort of) done, but it should remain so with the refactor, and we should actually be able to build the documentation as well.
Once OS-specific modularity is implemented, we can start implementing functions using different operating systems. Linux is one such target.
In order to better define the SWIG bindings, it is necessary to define C++ bindings which mirror them (in part because C++ bindings cannot be created through SWIG).
Some early CDs have hidden pre-emphasis (i.e. it is marked in the subchannel but not the TOC), e.g. http://www.stevehoffman.tv/forums/showthread.php?t=86992 and http://www.studio-nibble.com/cd/index.php?title=Pre-Emphasis_(release_list) We should add a test to ensure that libcueify can detect these tracks (I do not expect this will need more than an explicit API to support it; the existing underlying APIs should already suffice).
Once OS-specific modularity is implemented, we can start implementing functions using different operating systems. FreeBSD is one such target.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.