Quote:

good luck with it : ) this is amazing that we will soon be able to encode in Flac in MorphOS, thank you for the hard work.
I won't probably use it though as it wouldn't make sense to encode on a slow morphOS machine while i have a Corei7 on the same desk. But this is so cool for those who use their morphos gear as their main machine.

> this is amazing that we will soon be able to encode in Flac in MorphOS

Encoding FLAC natively on MorphOS has been possible for at least 6 years, and for more than 9 years using m68k binaries:

http://www.amiga-news.de/en/news/AN-2003-02-00247-EN.html
http://www.amiga-news.de/en/news/AN-2003-03-00128-EN.html
http://aminet.net/package/mus/misc/flac-1.1.0
http://aminet.net/package/mus/misc/flac
http://downloads.morph.zone/find.php?find=flac
http://aminet.net/package/mus/misc/flac-morphos

What Krashan will provide however is a GUI-centric (MUI), better integrated (Reggae) and better optimized (AltiVec) way of doing it.

Time for some update. As I've reported before, demuxer has been already finished. Now all activity concentrates on decoder. Decoding FLAC frame header is now complete. Then there are 4 types of subframes. Subframe header decoder is done as well. Then what is left to do is decoding subframes contents:
1. Constant subframe is the easiest. It is usually used to encode silence at the start or end of music (or inside). Decoding it is a piece of cake, and I've already done it.
2. LPC subframe. It is the most compilicated one, but as it is the most common one, I'm currently working on it. Decoding of LPC subframes may be accelerated with AltiVec.
3. Fixed predictor subframe. It may be easily reduced to a special case of LPC. AltiVec accelerations apply as well.
4. Verbatim frame. In rare cases there is no point to compress a signal, as no compression can be achieved using FLAC algorithms. Then samples are just stored as is. While relatively easy to decode it is rarely found in real streams, so I've left it for the end. AV accelerations are possible here as well, but since verbatim frames are rather rare, overall gain would be not big.
There is also another optimization, which may be significant. I will go technical jargon here, so beware. The residual signal of predictor in FLAC is encoded with so called Rice encoding. In Rice encoding every audio sample consists of two parts. The first one uses unary encoding. Unary encoding is just some "0" bits followed by "1" bit. Count of these "0" bits is the encoded number. Usually these "0" bits are counted by shifting and masking, but PowerPC has a special instruction named cntlzw, which counts those "0" bits in hardware. This can mean serious speedup of decoding if bitstream reader is specifically designed to use the instruction. Note that it is a PowerPC core instruction, not AltiVec one, so even Efika (as well as G3 and Sam460) processor has it. As far as I was able to check, it is not used by libflac. I will keep you informed about results.

[ Edited by Krashan 20.12.2012 - 17:08 ]

@SoundSquare

Ever tried Flacapella bundled with MorphOS? :) And since this is for ripping CDs, the speed of a G4 is more than enough with encoding still being faster than ripping.

[ Edited by jacadcaps 20.12.2012 - 20:51 ]

i'll give it a try.
btw is there a 24bit 96khz soundcard that would be supported by MorphOS ? i'd love to be able to play my 24bit Flacs.

http://www.audio-evolution.com/drivers_mos/

@Soundsquare

Be cautious with choosing a card from the list - iirc the Terratec Aureon Sky card only supports 24/48, although the Terratec Producer Phase 22 supports 24/96

thanks for pointing it out, i should have mentioned "USB audio card"' as i only have a macmini and a powerbook. No USB card supported ?

Unfortunately not. Poseidon support is there, the problem is in pciusb.device not supporting isochronous transfers (used by audio & video devices).

Another report

While working on decoder I've decided to redesign it a bit. FLAC as a lossless format has multiple provisions for stream integrity. This gives an opportunity for writing stream validators or even repairing tools. To make it possible with Reggae, I've changed the way block extracting is done. FLAC decoder class provides some additional methods, which can be overridden by subclasses, allowing for extended control of decoding process.

The first method can be used for control of accepting a block. Its default implementation passes a block to decoder only if both header CRC-8 checksum and block CRC-16 checksum are valid. Block is rejected otherwise. An application can override this method and having a pointer to the complete undecoded block it may try to fix it in some way, or just force the decoder to decode it regardless of checksums.

The second method is called after decoding. This time application has access to decoded audio and to complete block info (including subblocks), so it can for example update detailed stream statistics.

Of course both these methods will be documented.

The next step: I've used API described in my last post to create a simple MUI based FLAC file validator/analyser. It is called Flacochlorine. It scans FLAC file, validates all the block and displays information about each block. The tool has multiple purposes:
- It is a testcase for my FLAC code.
- It shows how to use extended FLAC API of flac.decoder and flac.demuxer for detailed FLAC analysis.
- It will be useful to me for encoder profiling.
- It may help in repairing of [slightly] damaged FLAC files.
Of course source code and latest FLAC classes included (note: no need to install them to SYS:, just make sure there are no duplicates anywhere). The next step is audio decoding proper.

Impressive

Flacochlorine 0.4 released with updated FLAC classes. Displays more info (audio related) about FLAC blocks: number of audio frames in a block, block position in decoded audio stream, stereo mode, compression ratios (for a block and accumulated). Plans for the nearest fututre: bitstream reader, subframe headers decoding.

I have another update of the FLAC bounty. Today the decoder "played" something for the first time. After implementing the decoder of residual signal, I've hacked it to send this signal directly to the output. Of course without reconstruction stage it sounds rather harsh and definitely not lossless. Anyway it verifies that following stages are now complete and fully functional (and also, as far as I can see, have no obvious bugs):

- block extractor
- block checksum and block header checksum calculator
- block header decoder
- subblock header decoder
- bit reader (and it uses this nice cntlzw PowerPC instruction )
- Rice code decoder

What is still missing?

- signal reconstruction for LPC and fixed predictors
- stereo re-correlation

I've already taken some steps to make the decoder faster than libflac, however there is no point to test speed before testing compatibility with the standard. Decoder producing bad output is useless, no matter how fast it is. My bit reader is implemented in macros, so its state is kept in processor registers. This and already mentioned cntlzw instruction used for decode unary numbers should make Rice decoder fast. Unfortunately such bit-juggling algorithms are hard to vectorize, so AltiVec won't be used for them. On the other hand signal reconstruction and stereo processing may be easily vectorized, so I expect significant speedups for G4/G5 users.

My further plans are simple. I will implement missing stages, without optimizations for now. Then standard conformance tests will be performed. I will test multiple files (grabbed from Internet as well as prepared with libflac encoder intentionally) and compare output of my decoder with the reference one. I will also release beta version publicly so it can be tested on many more FLAC files by you. When these tests will pass, there will be the time for speed benchmarking and further code optimizations.

Quote:

Thankyou for your fantastic ongoing work with Reggae - it's one of the feature of MorphOS I emphasise when discussing MorphOS with other (non-Amiga) geeks.

Will the updates allow u1ynth and multiplay to generate/play flac encoded files? I'm looking forward to some extensive testing (aka an excuse to kick back and enjoy some fine quality music)

[ Edited by boot_wb 20.05.2013 - 14:22 ]

@boot_wb

Will the updates allow u1ynth and multiplay to generate/play flac encoded files?

The first stage, I'm working on currently is the decoder. After finishing it:

- Ambient will play FLAC on doubleclick.
- Jukebox will play FLAC.
- Zormanita will load FLAC and convert it to WAVE/AIFF/raw.

The second bounty stage is encoder. After finishing it:

- U1Synth (and Zgrzytor ) will save its output as FLAC.
- Zormanita will convert to FLAC.

Of course any other program using Reggae for audio handling will take advantage.

This time one image instead of a thousand of words:

http://krashan.ppa.pl/temp/first_decode.png

Due to various circumstances I will be not able to complete the FLAC bounty in any reasonable timeframe. Then I've decided to give up the bounty. All the bounty cash remains at disposition of pampers, the bounty administrator.

Quote:

Sorry to hear that Krashan, but such is life - hopefully good things taking up your free time. Any plans to continue outside the bounty context?

It seems a shame given the hard work you've put in that you won't get the bounty money, but to lower myself to the level of management-speak for a moment, I do think it's good for the integrity fo the bounty system to keep bounties 'SMART' (Specific, Measurable, Achievable, Relevant, Timed) so can appreciate your/Pampers decision.