- A few years ago now a strange 'buzzing' from the HiFi was heard when playing CDs. Speakers, connections and wires were all checked, amplifiers were changed but all was well. Then it became clear that LPs and all older CDs played perfectly, only the modern CDs buzzed.
Eventually the search ended at the DAC/CD combination when it was discovered that the (pro-audio) DAC was sensitive to DAC overload when it was fed from modern CDs. The problem became clear when the CD was ripped and then examined with Audacity, exposing the full horror and scale of the problem.
CuteStudio's initial TxtDeClip was originally a text-only command line program created to fix this problem in WAV files, which could easily be ripped from the offending CDs.
SeeDeClip3 was the first commercial graphical/batch product to roll out this fix. It was great for fixing WAV collections for later listening and repairing the odd track that was mistakenly clipped during recording, it's saved a few projects around the world.
As music collections grow one ends up with a variety of file formats, duplicates, and the actual daily access to that collection becomes occasional and limited. Plus all of the tunes downloaded from iTunes/Amazon etc are still clipped. So this unsatisfactory condition prompted the writing of SeeDeClip4, to fulfill basic requirement most people have:
To be able to access your entire music library from any device at the best possible quality.
To achieve this requires:
- Networking and outputting text, graphs, images and audio on a wide variety of devices.
The proper app for this is a web browser, i.e. SeeDeClip now had to become a web program.
..but it still has to function like a modern app.
..and being a webserver makes it multi-user and multi-tasking.
SeeDeClip4 is a major jump forward in both audio and software technology.
This software was only possible due to the support of SeedeClipV3 customers, so a big thanks to them.
The diagram below shows the architecture behind SeeDeClip4. At the top is the listener and his browser, at the bottom is the file system with the music. SeeDeClip4 is then in the middle connecting the listener to his music.
SeeDeClip4 is around 330kB in size.
- The first thing to note is that the program is threaded - i.e. it does a number of things at the same time, so imagine it as a teaming hive of choreographed activity that only stops when you pause the music.
All web traffic is buffered in FIFOs, so stuff can be written out around the time new stuff is still being generated. Outgoing FIFOs are throttled to prevent memory exhaustion, so when a 1GB stream is requested and you press 'pause' the task is halted for a while, rather than letting that 1GB build up in memory. These general purpose FIFOs are also used for base64 and json I/O.
Behind each page the CTL scripting system interfaces to the core modules. One such module is 'control' that manages each control, option and value, and custom items like graphs. This text is managed by the 'text' module.
Caching is fundamental to the system. All audio data is segmented and managed via this cache. The cache is a single, thread aware, manager that manages around 5 different actual caches, e.g. the imported files, META data, segments, analysis results.
The declipper sits in the middle behind a 'processed segment' cache aquire, getting raw audio from the 'raw segment' cache as demanded. It has a single job - to fixing clipping damage.
Note the 'meta' box, SeeDeClip directly reads file meta data (artwork or embedded artist/album/track name text) and does not use external importers for this. Importers are purely for audio data.
SeeDeClip4 and your/any browser forms a Client-Server pair.
The server is a web-site, like any other website, except you run(host) it on your computer, by running SeeDeClip4.
The SeeDeCip installation creates the whole website for you, and when you tell it where to find your music files, it becomes your own handy site with all your music on it. The server needs to have a/some disk(s) with all your music files on it.
Ideally it will have a decent CPU too, although SeeDeClip4 is efficient music files contain a lot of data to be processed.
The client is your browser, like Safari, Chrome, Firefox, IE etc.
It's the tool you use to browse the internet.
Inside the browser Apple, Google, Microsoft and the open source community have been creating a tool for displaying information, operating forms, drawing pictures and playing music. I.e. exactly what we need.
Websites use the HTTP protocol and are contacted by typing in the correct address and port number.
So your SeedeClip4 website will be at the address of your server, on port 8000 unless you've changed it in the settings.
Your client can be the same computer as the server or any other device on the same network.
The ability to update the program is built in. The setup program is actually two programs in one:
- seedeclip4 boot manager
The first seedeclip4 to run actually decides to run itself, or one of the two update slots. When you first install the update slots are empty so it runs itself, and depending upon how the update went it will run the most recently downloaded of slot0 or slot1.
This also allows seamless restarts and an extra degree of robustness in both operation and update.
|Why didn't you just use Apache and PHP?|
|Apache and PHP also covers LAMP, the popular website stack used on the internet.|
- SeeDeClip needs to run on all sorts of different machines, frankly a single program is a lot easier to manage than LAMP for any non IT person.
SeeDeClip4/CTL is a faster (and considerably smaller) web server/scripting system than LAMP.
SeeDeClip4 can be upgraded very easily, much more easily than LAMP.
Battling with configs for Apache/Apache2 and PHP etc. isn't as much fun, it's more IT than engineering. Real people may also want to use this.
|What is Seedeclip4 written in?|| It's written in 'C' and uses pthreads.|
For the techies - Development is shared between Linux and Apple OS X:
- Linux for (general dev, valgrind, Win32 cross compilation (mingw-w64)
Apple for Xcode, Cocoa, lldb (lldb is far better than gdb).
|Can it use all the cores in a multi-core processor?|| Yes indeed.|
|Why doesn't it use JQuery? || Because it doesn't need to.|
|Why doesn't it use https? || Because someone might hack in and steal a few seconds of 'Love Machine'?|
Secure sockets are only useful to protect secure information, of which there is none.