When I first became aware of the Float16 type I found it interesting in terms of maybe having potential as a possible lossy storage type.
Attached is a processed version of the sample in this thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86738&view=findpost&p=743401) which has been decoded back to PCM. The processing is as follows (at this stage as there is no player that I am aware of):
Input file Sample [PCM] > FLOAT16 > [PCM] > Output File.
The conversion from integer to Float16 reduces the number of significant bits of the 24-bit sample to (a maximum of) 11. There is therefore an amount of added noise due to truncation. The added noise has been noise shaped using SG's adaptive noise shaping method as used in lossyWAV.
Original Sample (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6362)
Lossy Float16 Processed Sample [edit] removed due to TransPCM executable / foobar2000 Float16 playback availability, 29th May 2012. [/edit]
If the 24-bit coded sample is encoded with FLAC (wFormatTag left as 0x0001 as FLAC does not handle Floating Point samples and wBitsPerSample is left as 24) there is a saving of in excess of 20% in filesize.
I don't see any practical advantage using this storage type for native 16-bit PCM.
Changelog:
TransPCM beta 0.1.3a 30/05/2013- Bug fix in Float24 handling (thanks Bryant!).
- Bug fix in WAVE_FORMAT_EXTENSIBLE chunk handling (thanks again Bryant!).
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
TransPCM beta 0.1.2 02/06/2012- Modification to adaptive noise shaping for 44.1/48kHz input;
- Amendment to tracer fingerprinting.
[/size]
This differs from simply reducing the bit depth?
Yes - in that values up to c. +/- 2^31 can still be stored (with an appropriate scaling factor). The granularity changes as sample absolute values get bigger. In this way, the original dynamic range can be preserved more effectively.
ABS(Input Sample) = 0 to 2047 : Output difference = 0;
ABS(Input Sample) = 2048 to 4095 = Output difference : 0 to -1;
ABS(Input Sample) = 4096 to 8191 = Output difference : 0 to -3;
ABS(Input Sample) = 8192 to 16383 = Output difference : 0 to -7;
ABS(Input Sample) = 16384 to 32767 = Output difference : 0 to -15;
ABS(Input Sample) = 32768 to 65535 = Output difference : 0 to -31;
etc.
Isn't this pretty much what ADPCM does? Except I guess without the differential encoding.
You mean a-Law/µ-Law?
Makes me wonder how many bits suffice to code the range -32768...32767. IOW, let the section "ABS(Input Sample) = 16384 to 32767" be the outermost one. Is a float13 enough?
Chris
Attached is a processed version of the sample in this thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86738&view=findpost&p=743401) which has been decoded back to PCM. The processing is as follows (at this stage as there is no player that I am aware of):
Input file Sample [PCM] > FLOAT16 > [PCM] > Output File.
What you are describing is very similar to WavPack lossy. The difference is that you also want to add a decorrelation step before truncating to float16 to reduce the magnitude of the samples. This could be as simple as using the delta between samples, but it would be even better to have an adaptive filter to better handle some difficult cases.
The plan was to simply set wFormatTag= 0x0003 and wBitsPerSample =16. Any compliant player could play the WAV file without any decoding.
float16 could be very efficient on GPU hardware if that is relevant to you.
-k
The plan was to simply set wFormatTag= 0x0003 and wBitsPerSample =16. Any compliant player could play the WAV file without any decoding.
From experience, I doubt many media players will play that.
I understand that currently players are rather unlikely to accept a 16-bit floating point WAV file. However, the RIFF standard effectively allows the use of Float16 even if it wasn't a standard at the time that the RIFF standard was set.
Decoding Float16 values is trivial - I have written a basic decoder (no NaN, Infinity handling) to both Float64 and (scaled) Integer output in Delphi seperately in x86/x87 - not too many lines of code per sample.
Below is Delphi / IA32 & x87 code used to encode Double to Float16 and decode Float16 to Double (actually extended [80-bit] in this case). Hopefully someone will find it useful.
Compatibility at a player level would be a great starting point (i.e. simply playing a RIFF WAVE with wFormatTag=0x0003 and wBitsPerSample=0x0010).
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
//==============================================================================
//
// Float16 encode / decode functions;
//
// 2011 Nick Currie
//
//==============================================================================
Type
Float16 = Word;
SingleRec = Packed Record
Case Integer of
1:(Single : Single);
2:(Integer : Integer);
3:(Words : Array[0..1] of Word);
4:(BytePx : Byte; WordP1 : Word;);
5:(Bytes : Array[0..3] of Byte);
End;
DoubleRec = Packed Record
Case Integer of
1:(Double : Double);
2:(Int64 : Int64);
3:(Integers : Array[0..1] of Integer);
4:(Words : Array[0..3] of Word);
5:(BytePx : Byte; WordP1,WordP3,WordP5 : Word;);
6:(Bytes : Array[0..7] of Byte);
End;
ExtendedRec = Packed Record
Case Integer of
1:(Extended : Extended);
2:(Int64 : Int64);
3:(Integers : Array[0..1] of Integer);
4:(Words : Array[0..4] of Word);
5:(Bytes : Array[0..9] of Byte);
End;
Var
Powersof = Packed Record
two : array[-1024..1023] of Double;
End;
{$IFNDEF USEASM}
//============================================================================
Function F80_to_F16(F80_Value : Extended) : Float16;
//============================================================================
Var
Exponent : Integer;
Sign : Word;
Begin
//============================================================================
Sign:=ExtendedRec(F80_Value).Words[4] and $8000;
If (F80_Value=0) then
F80_to_F16:=Sign
else
Begin
Exponent:=(ExtendedRec(F80_Value).Words[4] and $7FFF)-$3FFF;
ExtendedRec(F80_Value).Words[4]:=ExtendedRec(F80_Value).Words[4] or $3FFF;
if Exponent>15 then
F80_to_F16:=Sign or $7C00
else
If (Exponent>-15) then
F80_to_F16:=(Sign or ((Exponent+15) shl 10) or ((ExtendedRec(F80_Value).Words[3] and $7FFF) shr 5))
else
if Exponent>-25 then
F80_to_F16:=(Sign or (ExtendedRec(F80_Value).Words[3] shr (-Exponent-9)))
else
F80_to_F16:=Sign;
End;
//============================================================================
End;
//============================================================================
{$ELSE}
//============================================================================
Function F80_to_F16(F80_Value : Extended) : Float16; Assembler;
//============================================================================
asm
push ecx
push edx
xor eax,eax
xor edx,edx
mov cx,word ptr F80_Value+8
mov dh,ch
and dh,$80
and cx,$7FFF
jz @@EX
sub cx,$3FFF
cmp cx,-$19
jle @@EX
mov ah,$7C
cmp cx,$10
jge @@EX
@@01: mov ax,word ptr F80_Value+6
cmp cx,-$0F
jg @@02
neg cl
sub cl,$09
shr eax,cl
jmp @@EX
@@02: add cl,$0F
shr ax,$05
shl cl,$02
and ax,$03FF
or ah,cl
@@EX: or ax,dx
pop edx
pop ecx
End;
//============================================================================
{$ENDIF}
{$IFNDEF USEASM}
//============================================================================
Function F64_to_F16(F64_Value : Double) : Float16;
//============================================================================
Var
Exponent : Integer;
Sign : Word;
Begin
//============================================================================
DoubleRec(F64_Value).Double:=F64_Value;
Sign:=DoubleRec(F64_Value).Words[3] and $8000;
If (F64_Value=0) then
F64_to_F16:=Sign
else
Begin
Exponent:=(((DoubleRec(F64_Value).Words[3] and $7FF0) shr 4)-$3FF);
DoubleRec(F64_Value).Words[3]:=((DoubleRec(F64_Value).Words[3] and $000F) or $3FF0);
if Exponent>15 then
F64_to_F16:=Sign or $7C00
else
If (Exponent>-15) then
F64_to_F16:=(Sign or ((Exponent+15) shl 10) or ((DoubleRec(F64_Value).WordP5 shr 2) and $3FF))
else
if Exponent>-25 then
F64_to_F16:=(Sign or (((DoubleRec(F64_Value).WordP5 or $1000) and $1FFE) shr (-Exponent-12)))
else
F64_to_F16:=Sign;
End;
//============================================================================
End;
//============================================================================
{$ELSE}
//============================================================================
Function F64_to_F16(F64_Value : Double) : Float16; Assembler;
//============================================================================
asm
push ecx
push edx
xor edx,edx
xor eax,eax
mov cx,word ptr F64_Value+6
mov dh,ch
and dh,$80
and cx,$7FF0
jz @@EX
shr cx,4
sub cx,$3FF
cmp cx,-$19
jle @@EX
mov ah,$7C
cmp cx,$10
jge @@EX
@@01: mov ax,word ptr F64_Value+5
shr ax,2
and ax,$03FF
cmp cx,-$0F
jg @@02
or ah,$04
neg cl
and ax,$07FF
sub cl,14
shr eax,cl
jmp @@EX
@@02: add cl,15
shl cl,2
or ah,cl
@@EX: or ax,dx
pop edx
pop ecx
End;
//============================================================================
{$ENDIF}
{$IFNDEF USEASM}
//============================================================================
Function F16_to_F80(F16_Value : Float16) : Extended;
//============================================================================
Begin
//============================================================================
if F16_Value and $8000<>0 then
Begin
if ((F16_Value and $7FFF)=0) then
F16_to_F80:=-0
else
if ((F16_Value and $7C00)=0) then
F16_to_F80:=-(F16_Value and $3FF)*powersof.two[-24]
else
F16_to_F80:=-((F16_Value and $3FF) or $400)*powersof.two[((F16_Value shr 10) and $1F)-25]
End
else
Begin
if F16_Value=0 then
F16_to_F80:=0
else
if ((F16_Value and $7C00)=0) then
F16_to_F80:=(F16_Value and $3FF)*powersof.two[-24]
else
F16_to_F80:=((F16_Value and $3FF) or $400)*powersof.two[((F16_Value shr 10) and $1F)-25]
End;
//============================================================================
End;
//============================================================================
{$ELSE}
//============================================================================
Function F16_to_F80(F16_Value : Float16) : Extended;
//============================================================================
asm
push ecx
push edx
movzx eax,F16_Value
mov dl,ah
and ax,$7FFF
jnz @@01
fldz
jmp @@EX
@@01: fld1
test dl,$80
jz @@02
fchs
@@02: mov ecx,eax
and ax,$3FF
shr cx,10
mov edx,1000
push eax
and cl,$1F
jz @@03
or word ptr [esp],$400
mov dx,999
add dx,cx
@@03: fimul dword ptr [esp]
fmul qword ptr powersof.two[edx*double_size]
@@04: pop eax
@@EX: pop edx
pop ecx
//============================================================================
End;
//============================================================================
{$ENDIF}
[/size] [edit] Code update. [/edit]
HalfPrecision beta 0.0.2cd attached. [bugfix] [superseded].
HalfPrecision is a tool to convert PCM in WAV format to Float16 in WAV format. Noise is added during the conversion process. By default this noise is adaptively shaped, however fixed noise shaping is also available along with the option to disable all noise shaping.
The -P, --precision <n> parameter selects the number of mantissa bits to use (8<=n<=11). Reducing the number of mantissa bits increases added noise.
By default, processed audio is output in Float16 format. Using the --decoded parameter converts the processed audio from Float16 back to the PCM in the original sample bitdepth (which may add a further small amount of noise) to allow the audio to be played in existing players.
NB: the Float16 audio is normalised in the range ±65504.0 rather than the standard ±1.0 (32bit and 64bit floating point audio). This allows a greater dynamic range of sample values (±65504 to ±6.1035E-05 [normalised]; ±5.9605E-08 [denormal]) to be stored. Returning samples to expected ±1.0 range is achieved by simple multiplication by 2^-16.
Bug-reports, comments and (constructive) criticism are welcomed.
foobar2000 1.1.9 beta1: "Implemented experimental support for 16-bit floating-point WAV files."
HalfPrecision beta 0.0.2e attached [superseded]. Fix to allow encoding to lossy.wav (and optional correction file) using foobar2000. "--stdinname %d" must be used in the command line parameters.
It occurs to me that a free-to-use (and platform agnostic) analog to HDCD could be created using Float16 encoded PCM written to a conventional CD. The trick would be to in some way tell the (software presumably) player that the audio was encoded in Float16. I'm guessing some sort of LSB encoding (minimal noise) of a periodic nature, maybe 32 to 64 LSBs per (codec-block x channels)?
[edit] beta 0.0.2e superseded [/edit]
I once had an idea for how to encode audio data. Take the square root of each data point, keeping the original sign. Decoding consists of squaring the encoded value, again keeping the sign. The result is that you lose about one bit of resolution on full-scale values, but you almost double the number of bits on small values.
For example, take 24 bit signed integer data, square root it and keep 12 bits. The values decode back to 24 bits with 15 bits of resolution on full-scale values.
That would be one way of doing it. However sample size range would be ±32767² to ±1², i.e. 1.0737E+09:1 . Sample range for Float16, as stated above, is ±65504 to ±6.1035E-05 [normalised]; ±5.9605E-08 [denormal], i.e. 1.0732E+09:1 [normalised]; 1.0990E+12:1 [denormal].
One idea for a signature / watermark to indicate Float16 encoding would be to use the bit pattern of 'Float16' with a bit inserted at either end and between the bits from each character, i.e. $231B0DE613A0C46C. This, when evaluated as a double precision float, equates to 1.41990141750237441E-0139. This pattern could be inserted, one bit per 7 samples, with a recurrence of, say, 512 samples, irrespective of number of channels (data span = 441 samples).
HalfPrecision beta 0.0.2f
attached [edit] superseded [/edit].
Changelog:
- Now outputs "halfp" and "hpcdf" files, i.e. halfp.wav and hpcdf.wav.
- Fixes to encoding to ensure proper coding when precision limited to fewer than 10 mantissa bits.
- Tweaks to adaptive noise shaping coefficients.
HalfPrecision beta 0.0.2g
attached. [edit] Superseded. [/edit]
Changelog:
- Output type can now be selected from 16/32 bit float; 16/24/32 bit integer;
- Valid input types now include 8*/16/32 bit float; 8/16/24/32 bit integer;
The so called 8 bit floating point type turned up when I was searching for details of the Float16 type some time ago. The 8 bits are comprised: sign / 4-bit exponent / 3-bit mantissa, exponent bias is -2, minimum non-zero = ±1; maximum=±122880. Precision is basic (i.e. 0 to 7 are denormal (integer, exponent=0) then 8 upwards, 1.000 to 1.875 x 2^(exponent+2)). I'm still evaluating this type to see if merits further work.
Output to 8-bit unsigned integer is not yet enabled - I'm still trying to iron out some issues with clipping and adaptive noise shaping.
Nick.C Thank you for your innovation.
It remains to add support FLOAT16 in FLAC, WavPack, TAK...
P.S. lossyWav not correctly support FLOAT16.
@Didjeridoo: Thanks - I am also looking forward to compatibility with a lossless format. The codebase for HalfPrecision is that of lossyWAV, so it is not inconceivable that an updated version of lossyWAV will appear at some point with the input capabilities of HalfPrecision. Output will still only be integer PCM though.
As an aside, and taking on board an early comment by Chris, I am also working on implementing read/write capability for µ-Law and A-Law samples.
HalfPrecision beta 0.0.2h
attached. [edit] Superseded [/edit]
Changelog:
- Now reads / writes CCITT 8-bit µLaw and ALaw;
- Now writes 8-bit unsigned integer.
- Work on so-called 8-bit float terminated after µLaw and ALaw implementation.
Nick.C I watch all the moves and develops
Is not the end, FLOAT24 also needed))
P.S. foobar2000 not read / write CCITT 8-bit µLaw and ALaw.
(http://i5.pixs.ru/thumbs/8/5/8/pictjpg_1616886_3345858.jpg) (http://pixs.ru/showimage/pictjpg_1616886_3345858.jpg)
P.S. foobar2000 not read / write CCITT 8-bit µLaw and ALaw.
It does read them.
Do you have any sample of command line for foobar.
HalfPrecision beta 0.0.2i
attached. [edit] Superseded. Fundamental change to 24-bit float handling in progress. [/edit]
Changelog:
- Addition of Float24 read/write capability (s/e7/m16, bias=63).
- Code improvements to handling of Float16 precision;
- Rewrite of sample conversion code.
@Ljubo44:
Encoder: c:\windows\system32\cmd.exe
Extension: halfp.wav
Parameters: /d /c "f:\userdata\bin\halfprecision" - --stdinname %d -w -silent
on 16/44,1 size is same after compress halfp.wav 16 floating to flac again.. But Differences found: 4776996 sample(s) of 12 789 000. peak: 0.0010986.
Sorry Nick, i am noob for this your new tool, but following you to learn something
.... after compress halfp.wav 16 floating to flac again..
I'm a bit confused as you shouldn't have been able to compress again with FLAC as it doesn't support wFormatTag=$0003 (floating point).
You are right, I used foobar 1.1.9 to convert to flac. In dbpoweramp dont work with any lossless codec. hm
HalfPrecision beta 0.0.2j
attached. [edit] Superseded. [/edit]
Changelog:
- Now reads / writes 24-bit Floating point (shortened 32-bit float).
HalfPrecision beta 0.1.0a
attached. [edit] Superseded. [/edit]
Changelog:
- Change to -P, --precision parameter. Takes a value in the range -8<=n<=0, i.e. new_mantissa_precision = old_mantissa_precision + n.
- Modifications to Float32 and Float24 handling - now uses -P, --precision parameter to reduce mantissa bits as for Float16.
- Optimisation of uLaw and ALaw encoding / decoding.
I hope the developers do not ignore innovation
foobar2000 1.1.10 beta 1 adds Float24 support - released today!
When I first became aware of the Float16 type I found it interesting in terms of maybe having potential as a possible lossy storage type.
Can you tell me what is the goal to have another lossy format while MP3 (popular) and AAC (very good quality but less popular) exist ?
The Float16 is smaller ?
While we have big HD, the size don't really matter and portable unit like ipod, cells phone don't play float16.
Ty
@pompon:
This is different from those coding schemes, in that it is designed to lose information more transparently than AAC (and especially mp3). Obviously there is very little hope of any lossy codec ever becoming nearly so popular as those two codecs, but I see absolutely nothing wrong with continued innovation in terms of improving both quality and coding efficiency. After all, there are still killer samples around for 320kbps mp3, which make it ABXable from the lossless source, so a lossy codec which is able to lose quality imperceptibly on a very consistent basis while achieving low bitrates is always in demand for me, and for many others I'd imagine.
I don't find this innovation to be at all pointless.
Right then people - HalfPrecision needs a new name.
The program now reads and writes nine different formats in the RIFF WAVE container:
- Float16;
- Float24 (truncated Float32);
- Float32;
- 8-bit unsigned integer;
- 16-bit signed integer;
- 24-bit signed integer;
- 32-bit signed integer;
- µLaw (8-bit pseudo float);
- ALaw (8-bit pseudo float).
So, any of the formats can be read and written to any of the other formats.
Just added:
- Correction files in format appropriate to both input and output sample type;
- CRC32 / CRC16 check of audio when creating correction files to allow checking of successful reconstitution.
.... back to the name - I'm thinking "TransPCM". Suggestions?
NB: the Float16 audio is normalised in the range ±65504.0 rather than the standard ±1.0 (32bit and 64bit floating point audio).
That's going to be a huge surprise for any software that naively implements "normal" floating-point behaviour on 16-bit data. And doesn't that eliminate
all of floating point's clipping headroom?
Anyway; what I was going to say was that if you take all the negative values and eor them with 0x7fff, that should look fairly linear to flac, and it may have a reasonable shot at compressing it. Except the normalisation probably leaves a huge discontinuity across zero because denormal LSBs won't line up with 24-bit LSBs.
It might have some chance of compressing better than 24-bit native, though. Have you tried it?
.... a surprise, yes, however as the standard has not become widespread in terms of implementation then I think that Float16 being different is understandable / acceptable in the same way that 8-bit integer is unsigned with a 128 offset compare to 16/24/32 bit signed integers with no offset.
[edit] In terms of headroom, due to the added noise associated mantissa bit reduction, I would expect Float16 to be a final format rather than an interim step for further processing. Use of the full range available in Float16 was a very conscious decision to maximise range (min sample value to max sample value). Also, there is nothing stopping someone reducing the scale of the audio prior to converting to Float16. [/edit]
In my testing, Float16 in a 24-bit sample container compressed better than the same number of 24-bit integer samples upon which the Float16 samples were based. Unfortunately, now that HalfPrecision stores the FMT.wFormatTag properly (0x0003 for Float), FLAC will not compress Float16 output.
HalfPrecision beta 0.1.0b attached. [edit3] superseded, 29th May 2012 [/edit]
- Correction files implemented;
- CRC32 and CRC16 calculated and stored for audio data to allow checking of successful recombination;
- Code speedups.
[edit2] experimental Adaptive Noise Shaping coefficients snuck through.... beta 0.1.0b replaced. [/edit2]
Well, by "huge surprise" I mean "destroy your speakers", and by "any software" I mean that I have to contact my previous employer and have them check to see if I committed that code before one of these files gets into a mobile phone and is played at high volume through a set of earbuds.
In terms of headroom, due to the added noise associated mantissa bit reduction, I would expect Float16 to be a final format rather than an interim step for further processing.
This raises the question of why you need so much low-level resolution, then.
It would surprise me if, when using any type of float where the expected range is ±1.0 but the available range is massive (i.e. 10^38 or 10^308), no checks were made by the decoding software on the inbound data to ensure that these limits were adhered to.
As this potential audio type is in its infancy, common practice is not yet defined (although it could be *assumed* that the treatment would be the same as for Float32).
Why maximise resolution? Simply, because it's there to be used. Why limit the type to a range of ±1.0 to 5.96E-08 (i.e. 2^24:1) instead of using ±65504 to 5.96E-08 (i.e. almost 2^40:1)? One of the complaints commonly made against 16-bit integer is lack of resolution compared to relatively commonly available 24-bit integer. The adoption of ±65504 takes the range of the Float16 type beyond that of 32-bit integer.
Well it's not really in its infancy. I included 16 bit float (part of the logical extrapolation on power-of-two bit depths) in a file format proposal in 2005, and a couple of years ago the same thing came about as an inevitable consequence of passing the bit depth (whatever it maybe) to a floating-point conversion routine which supported 16-bit as well as 32 and 64 bit precision.
What checks do you propose to perform, and what is the proper action to take on different results?
I don't mean for anything to be changed on my account, anyway. I've already asked for my old code to be reviewed and deleted as appropriate.
I accept that the Float16 proposal must have been in existence for some time before it was adopted in the revised IEEE-754 [2008], but it is fair to say that very little Float16 (as defined in the 2008 revision) encoded audio has been promulgated.
I would expect that any player would perform a bound check on any input format for which not all possible values are permissible, i.e. no check required for 8, 16, 24 or 32-bit integer; limit check required for 32 and 64-bit float (permissible values ±1.0; Float32 Max/Min: ±3.4028234 × 10^38; Float64 Max/Min: ±1.7976931348623157 x 10^308), along with ±INF and NaN checks. Allowing Float16 to use ±6.5504 x 10^4 increases range and reduces checking to ±INF and Nan.
Sorry to have proposed a handling of the type contrary to the handling of 32 and 64-bit float (and causing you a retrospective code change!), but, as stated earlier, it maximises the potential of the type.
I fear that I may need a little more clarification as to the benefits of this over, say, lossyWAV, in terms of both resolution and efficiency in reducing information from 24-bit samples. Any more comparisons would be most welcome (and level-matching would be appreciated also, as the two files in the OP are a couple dB apart.)
Not being able to recompress to FLAC is unfortunate. Is there any kind of workaround possible for this?
Thanks for your continued development of this codec.
Hi there,
Using HalfPrecision to convert from 24-bit integer PCM to 16-bit floating point will add a small amount of noise to the output while at the same time reducing the uncompressed file-size by approximately one-third.
The lossless file, when downloaded, has no ReplayGain information. The lossy version has ReplayGain information appended (using the latest R128Gain in foobar2000). If new ReplayGain values are calculated for both files then you will find that they are within approximately 0.01dB of each other (+2.97dB and +2.98dB respectively).
I agree about the lack of lossless compression - I am quietly hoping that one of the lossless codec developers takes up the challenge. As I said previously, when an incorrect wFormatTag is used ($0001 for Integer rather than $0003 for Floating Point) then over 20% filesize saving is made compressing 16-bit FP-PCM instead of 24-bit Int-PCM.
This is not really a codec - rather an alternative representation of the audio data - (practically) no decoding is required by the playback software.
Nick.
Thanks for the reply, Nick.
Looking at the ReplayGain through Foobar, you're quite right. Really should've checked on that before I posted what I did, since we should all be quite aware of the frailty of hearing + perception on this forum (I had perceived a volume difference after repeatedly flipping back and forth between the files.)
What is the approximate amplitude of the noise when not shaped?
TransPCM beta v0.1.1
attached. [edit] Superseded [/edit]
Changelog:
- Correction file creation capability removed (for now);
- Optional fingerprinting of Float16 output using the -t, --tracer parameter. Adds some (actually very little) noise to the output;
- Precision parameter removed (reduced mantissa bits).
The trace / fingerprint is intended to allow identification of Float16 output if written as CDDA. The fingerprint is "[Fp]" and is stored one bit every eight samples, channel hopping every bit. Repeat is every 256 samples. If interpreted as 16-bit integer, the Float16 audio is pretty nasty, but not totally unrecognisable in comparison to the original.
TransPCM beta 0.1.2
attached. [edit] Superseded. [/edit]
Changelog:
- Modification to adaptive noise shaping for 44.1/48kHz input;
- Amendment to tracer fingerprinting.
/d /c C:\bin\TransPCM_beta_0.1.2\TransPCM - --stdinname %d -O 1 -w --silent
Conversion failed: The encoder has terminated prematurely with code 50 (0x00000032); please re-check parameters
I dont know what means code 50. What's wrong here
Why do you have switches before the executable? And their differing format suggests they are for some other application.
(For readers’ reference: that error message is from foobar2000.)
What's wrong here
It depends on what you want to do. But "--stdinname %d" definitely seems wrong.
The use of --stdinname %d is to tell the program what filename to associate with the data taken from STDIN.
Error 50 (0x32) denotes that the string "tpout.wav" cannot be found in %d (i.e. all output files are expected to end "tpout.wav" - although this *should* have been documented....
The "/d /c" before "C:\.....\TransPCM" are parameters for cmd.exe which is called by foobar2000 to carry out the conversion.
I hope that this helps.
Rockbox now has added Float16 compatibility* - thanks saratoga!
Will have to get to work on an HDCD type decoding DSP for foobar2000 / Rockbox to allow incorrectly stored Float16 (i.e. as 16-bit integer) audio in FLAC, WavPack, etc to be correctly identified and converted.
*: in a WAV file.
No problem. Hope its useful to people.
TransPCM beta 0.1.3a attached to post #1 in this thread.