IPB

Welcome Guest ( Log In | Register )

> Upload forum rules

- No over 30 sec clips of copyrighted music. Cite properly and never more than necessary for the discussion.


- No copyrighted software without permission.


- Click here for complete Hydrogenaudio Terms of Service

50 Pages V  « < 26 27 28 29 30 > »   
Closed TopicStart new topic
lossyWAV Development, WAV bit reduction by 2BDecided
Nick.C
post Dec 17 2007, 15:30
Post #676


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (Nick.C @ Dec 17 2007, 07:52) *
I'll have a look at the -1 btr issue, although, thinking about it, it should have no impact at all as when btr falls to zero then the block is merely stored and is not processed at all.
The bug is merely presentational - when btr is indicated as -1 then it is actually 0 and the codec_block is stored. This will be amended for beta v0.5.9

As an aside, could this method be applied to 32-bit float values, i.e. round the mantissa only? And would any of the lossless codecs make use of zero LSB's in the mantissa?


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
2Bdecided
post Dec 17 2007, 15:56
Post #677


ReplayGain developer


Group: Developer
Posts: 5060
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (jesseg @ Dec 17 2007, 11:48) *
QUOTE (halb27 @ Dec 17 2007, 01:56) *
b) The replaygain procedure doesn't process the sound. It just computes a volume correction value and stores it in the file so that the playback machinery is able to adjust volume according to this value (in case the playback machinery has a replaygain feature).
[snip]
The only form of 'sound processing' because of replaygain can occur on playback when there is something like a 'soft clipping prevention' feature with replaygain which usually can be switched off if not wanted.


Well that's not entirely true. In fact, if the replaygain code is handled in 16bits, it can easily cause an audible effect to be heard.
No, not "easily". "Potentially".

Of course, the effects of ReplayGain are almost always audible - it changes the volume!

However, 16bits are more than enough to accomplish this transparently for most audio signals. Not all, but most.

The potential for detecting the re-quantisation (or re-dithering) exists with extremely dynamic signals, where ReplayGain reduces the volume because substantial sections are relatively loud, but the listener cranks the volume up to concentrate on some relatively quiet sections. In these sections, the dither or quantisation may be audible.


A far greater and more common problem is owning a poor DAP with a hissy amplifier, low power etc, where ReplayGain will make everything too quiet and drop it into the noise floor.

Cheers,
David.


QUOTE (stel @ Dec 16 2007, 19:24) *
Sorry for not posting these sooner. I've been out all day.
I've attached 10 second samples. The issue happens 5 seconds in when encoding the sample.flac file.
Sorry, the M5_issue.flac isn't great quality but you can clearly hear the issue I'm experiencing.
Just to check...

M5_issue is mono. I assume your DAP is actually playing back in stereo?

Cheers,
David.
Go to the top of the page
+Quote Post
stel
post Dec 17 2007, 22:07
Post #678





Group: Members
Posts: 18
Joined: 8-June 06
Member No.: 31641



OK, I've spent some time this evening playing around with different encoder settings on my problem sample and I'm kicking myself with the results. The good news is that it's not lossyWAV that's at fault...

My problem was caused by the 'Bit Depth Control' settings in foobar2000. The 'Format is:' was set to lossy and 'Highest BPS mode supported:' set to 24. Setting the format to lossless(or hybrid) fixed the issue. I guess I've encoded everything at 24bit and my DAP isn't happy about it.

Apologies to everyone who spent time looking into it.
Go to the top of the page
+Quote Post
Nick.C
post Dec 17 2007, 22:15
Post #679


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (stel @ Dec 17 2007, 21:07) *
OK, I've spent some time this evening playing around with different encoder settings on my problem sample and I'm kicking myself with the results. The good news is that it's not lossyWAV that's at fault...

My problem was caused by the 'Bit Depth Control' settings in foobar2000. The 'Format is:' was set to lossy and 'Highest BPS mode supported:' set to 24. Setting the format to lossless(or hybrid) fixed the issue. I guess I've encoded everything at 24bit and my DAP isn't happy about it.

Apologies to everyone who spent time looking into it.
Many thanks for the subsequent investigations! My iPAQ won't even play 24bit.....

[edit] Interestingly, the difference between my 53 sample test set at 16 bit and 24 bit (Foobar WAV output) is about 40kB in 38.4MB [/edit]

This post has been edited by Nick.C: Dec 17 2007, 22:52


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
jesseg
post Dec 18 2007, 00:04
Post #680





Group: Banned
Posts: 218
Joined: 22-December 02
Member No.: 4194



QUOTE (stel @ Dec 17 2007, 15:07) *
The 'Format is:' was set to lossy and 'Highest BPS mode supported:' set to 24. Setting the format to lossless(or hybrid) fixed the issue.


You're the second person in this thread alone to run into problems from that setting. I would think they would have it set to lossless by default, but I guess not (or is it?)
Go to the top of the page
+Quote Post
Nick.C
post Dec 18 2007, 13:12
Post #681


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



I've been toying with looking at implementing (& optimising in IA-32) mixed-radix FFT's (i.e. non-power-of-two-length).

At present, they're *very* slow.

Is there a feeling that changing the timeframe of the fft analysis from 1.45msec (64 samples @ 44.1kHz) to, say, 1.497msec (66 samples @ 44.1kHz) or 23.22msec (1024 samples @ 44.1kHz) to 20msec (882 samples @ 44.1kHz) would be beneficial?

This would also allow better handling of WAV's which are other than 44.1kHz as the optimal FFT length could be calculated directly rather than using the existing 64 / 128 / 256 / 512 / 1024 sample lengths, e.g. 72 samples = 1.5msec @ 48kHz; 960 samples = 20msec @ 48kHz.

If it is considered to be of merit then I will progress the implementation / optimisation over the festive period, initially alongside the existing power-of-two FFT routine unless (until?) the mixed-radix method becomes acceptably fast.

This post has been edited by Nick.C: Dec 18 2007, 13:14


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Dec 18 2007, 15:32
Post #682





Group: Members
Posts: 2424
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



The best of possibilities that arise from such a generalization IMO comes with the long FFTs where a finer differentiation becomes possible. By now we only have the choice between a 512 and a 1024 sample FFT.

Anyway I can't imagine ist's a real benefit, even for a 48 kHz source which makes up for a ~10% difference in timing.

I once was worried about the overlapping of the 1024 sample FFT into the neighboring blocks (and I would still prefer the 5/8 partitioning I once suggested) which can also be reduced by using a say 882 sample FFT, but because of the very good quality we have I'm content with the way you do the FFT right now.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
2Bdecided
post Dec 18 2007, 16:10
Post #683


ReplayGain developer


Group: Developer
Posts: 5060
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



I think it's a waste of time. The exact numbers aren't important, and even in lossy codecs (where the exact numbers are important) they still stick to fixed values irrespective of the sample rate, with reasonable results.

Cheers,
David.
Go to the top of the page
+Quote Post
Nick.C
post Dec 18 2007, 16:34
Post #684


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (halb27 @ Dec 18 2007, 14:32) *
The best of possibilities that arise from such a generalization IMO comes with the long FFTs where a finer differentiation becomes possible. By now we only have the choice between a 512 and a 1024 sample FFT.

Anyway I can't imagine ist's a real benefit, even for a 48 kHz source which makes up for a ~10% difference in timing.

I once was worried about the overlapping of the 1024 sample FFT into the neighboring blocks (and I would still prefer the 5/8 partitioning I once suggested) which can also be reduced by using a say 882 sample FFT, but because of the very good quality we have I'm content with the way you do the FFT right now.
QUOTE (2Bdecided @ Dec 18 2007, 15:10) *
I think it's a waste of time. The exact numbers aren't important, and even in lossy codecs (where the exact numbers are important) they still stick to fixed values irrespective of the sample rate, with reasonable results.

Cheers,
David.
Thanks guys - I'll park it. Only the presentational bug of -1 btr to be corrected for beta v0.5.9.

-shaping may get the bullet as it is really beyond my grasp of audio processing.

As things seem to be ticking along nicely, I think I'll concentrate on producing the correction file next.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
2Bdecided
post Dec 19 2007, 11:16
Post #685


ReplayGain developer


Group: Developer
Posts: 5060
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



I probably said this before, but I strongly advise borrowing the wavpack file format for that, as much as possible/relevant, because I'm sure David Bryant has worked through some of the issues that might be faced here. It might not be entirely applicable, but it's always good to re-use someone else's (good) work when they're happy for you to do so!

Cheers,
David.
Go to the top of the page
+Quote Post
Nick.C
post Dec 19 2007, 11:31
Post #686


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (2Bdecided @ Dec 19 2007, 10:16) *
I probably said this before, but I strongly advise borrowing the wavpack file format for that, as much as possible/relevant, because I'm sure David Bryant has worked through some of the issues that might be faced here. It might not be entirely applicable, but it's always good to re-use someone else's (good) work when they're happy for you to do so!

Cheers,
David.
My approach was going to be even more simplistic - write two WAV files, one lossy, one correction, then encode both in FLAC. I'm working on adding a FACT chunk to the WAV file - containing a null terminated string which will include lossyWAV version information, parameters used and date/time of processing (and ultimately the CRC32 of the lossless and lossy data) which would be written to both files.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Dec 20 2007, 09:49
Post #687


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (Nick.C @ Dec 19 2007, 10:31) *
I'm working on adding a FACT chunk to the WAV file - containing a null terminated string which will include lossyWAV version information, parameters used and date/time of processing (and ultimately the CRC32 of the lossless and lossy data) which would be written to both files.
I've successfully implemented a mechanism to insert a 160 byte FACT chunk immediately after the FMT chunk in the WAV file. This takes the form:
CODE
fact/152/lossyWAV v0.5.9 : 20/12/2007 08:46:57
-2 -cbs 512 -nts 0.00 -snr 21.00 -skew 36.00
-spf 22224-22235-22336-12347-12358 -fft 10101
If a file has already been processed, the FACT chunk will be found and lossyWAV will exit. When encoding in FLAC the --keep-foreign-metadata switch must be used to preserve the lossyWAV FACT chunk.

Thinking about it, I should make a bit more effort and make the FACT chunk variable length (up to a sensible maximum). In this way, the total length of the FACT chunk will be (8+string_length+(string_length and 1).

This post has been edited by Nick.C: Dec 21 2007, 12:23


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Dec 21 2007, 10:49
Post #688


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



lossyWAV beta v0.5.9 attached at post 1 of the thread.

Fixed btr -1 bug;
Implementation of FACT chunk inclusion in output when processed. lossyWAV will exit if it finds a lossyWAV FACT Chunk in a WAV file. FLAC required --keep-foreign-metadata switch to retain FACT chunk.

This post has been edited by Nick.C: Jan 1 2008, 15:25


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
jesseg
post Dec 22 2007, 08:52
Post #689





Group: Banned
Posts: 218
Joined: 22-December 02
Member No.: 4194



Could you have the exe return... something besides error level 1, when it actually has an error, such as the WAV file already having the lossyWAV flag? That will allow me, and others, to add handling for it into batch files and software.

Very good idea though. I'll release a new batch for iFLCDrop when I can get back a specific code for the "lossyWAV flag exists" error. With the error code returned I can make the script copy the source-file into the temp directory, and have it get encoded into FLAC anyways. smile.gif
Go to the top of the page
+Quote Post
Nick.C
post Dec 22 2007, 12:37
Post #690


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (jesseg @ Dec 22 2007, 07:52) *
Could you have the exe return... something besides error level 1, when it actually has an error, such as the WAV file already having the lossyWAV flag? That will allow me, and others, to add handling for it into batch files and software.

Very good idea though. I'll release a new batch for iFLCDrop when I can get back a specific code for the "lossyWAV flag exists" error. With the error code returned I can make the script copy the source-file into the temp directory, and have it get encoded into FLAC anyways. smile.gif
Very good idea, I'll start thinking about the codes needed and will post as beta v0.6.0 in a couple of days.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Dec 24 2007, 10:55
Post #691


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (Nick.C @ Dec 22 2007, 11:37) *
QUOTE (jesseg @ Dec 22 2007, 07:52) *
Could you have the exe return... something besides error level 1, when it actually has an error, such as the WAV file already having the lossyWAV flag? That will allow me, and others, to add handling for it into batch files and software.

Very good idea though. I'll release a new batch for iFLCDrop when I can get back a specific code for the "lossyWAV flag exists" error. With the error code returned I can make the script copy the source-file into the temp directory, and have it get encoded into FLAC anyways. smile.gif
Very good idea, I'll start thinking about the codes needed and will post as beta v0.6.0 in a couple of days.
Another thought - would it be useful to, say, "lossyWAV <wavfile.wav> -check" to allow the user to check for a processed file without trying to process it again?


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
jesseg
post Dec 24 2007, 13:16
Post #692





Group: Banned
Posts: 218
Joined: 22-December 02
Member No.: 4194



Yes, especially if it returned an error code if it was already processed. It would allow an application to check or batch check for lossyWAV or non-lossyWAV files... for whatever reason someone might want to do that. But even without an error code, it would be ok for non-automated or non-batch use I guess.
Go to the top of the page
+Quote Post
Nick.C
post Dec 24 2007, 13:20
Post #693


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (jesseg @ Dec 24 2007, 12:16) *
Yes, especially if it returned an error code if it was already processed. It would allow an application to check or batch check for lossyWAV or non-lossyWAV files... for whatever reason someone might want to do that. But even without an error code, it would be ok for non-automated or non-batch use I guess.
I would of course include an error code smile.gif following your request. You can even see the rifffact chunk stored at the beginning of FLAC files thanks to Josh's latest --keep-foreign-metadata switch, and Tiny Hexer file binary viewer / editor.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
singaiya
post Dec 24 2007, 20:03
Post #694





Group: Members
Posts: 365
Joined: 21-November 02
Member No.: 3830



Is lossyWAV's method similar to Wavpack lossy's method? I thought it was a different approach, but then seeing mention of correction files maybe they're more similar than I thought?
Go to the top of the page
+Quote Post
Nick.C
post Dec 24 2007, 20:10
Post #695


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



The concept of the correction file will be similar in that the lossless original will be able to be recomposed from the lossy.wav and the lwcdf.wav files by simple sample addition.

lossyWAV rounds LSB's to zero where the added noise of the rounding is calculated to be below a threshold value.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Dec 24 2007, 21:17
Post #696


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (Nick.C @ Dec 24 2007, 12:20) *
I would of course include an error code smile.gif following your request. You can even see the rifffact chunk stored at the beginning of FLAC files thanks to Josh's latest --keep-foreign-metadata switch, and Tiny Hexer file binary viewer / editor.
lossyWAV beta v0.6.0 attached at post 1 of the thread.

Error code = 16 on exit if WAV file has already been processed.

-check parameter included to allow checking without trying to process the file, error code = 16 if processed. [edit]It's not clear in the parameters that -check should only be used in the context: "lossyWAV <wavfile.wav> -check" as it will always exit after determining whether a lossyWAV FACT chunk exists.

This post has been edited by Nick.C: Jan 1 2008, 15:24


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
jaybeee
post Dec 29 2007, 18:06
Post #697





Group: Members
Posts: 410
Joined: 20-October 04
From: UK
Member No.: 17750



Thanks for the latest update Nick.C.
I personally think it's best to add download links to the first post in the thread; that way it's always easy to find smile.gif

I use foobar, the set up as per the lossywav wiki entry, and so do you think it's possible to preserve Replaygain tags? (I'm unsure if this is a foobar or lossywav issue).

This post has been edited by jaybeee: Dec 29 2007, 18:27


--------------------
http://www.health4ni.com/
Go to the top of the page
+Quote Post
Nick.C
post Dec 29 2007, 21:29
Post #698


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (jaybeee @ Dec 29 2007, 17:06) *
Thanks for the latest update Nick.C.
I personally think it's best to add download links to the first post in the thread; that way it's always easy to find smile.gif

I use foobar, the set up as per the lossywav wiki entry, and so do you think it's possible to preserve Replaygain tags? (I'm unsure if this is a foobar or lossywav issue).
David will correct me if I am wrong, but I've seen slightly different Replaygain values for the same track pre as opposed to post processing, so I don't know if retaining them is a good idea. It wasn't much though. lossyWAV does nothing at all with tags - that's all Foobar (thankfully).

I will edit the first post in this thread to reflect both its content and as the download point.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Dec 29 2007, 21:36
Post #699





Group: Members
Posts: 2424
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



How do you make foobar pass the replaygain information to the resulting (say) FLAC file?
I'd love to do that as my input ape files do have replaygain information.

I personally wouldn't care about slightly incorrect replaygain values (and I can't but imagine they are small).
The bigger problem to me is with replaygain that sometimes the replaygain values have to be corrected manually to achieve an equal loundness impression. I'd be happy if I could do these manual corrections just once in my ape files, and take profit of it whenever I encode them.

This post has been edited by halb27: Dec 29 2007, 21:38


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Jan 3 2008, 17:26
Post #700


lossyWAV Developer


Group: Developer
Posts: 1787
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



lossyWAV beta v0.6.1 now appended to post #1 of this thread.

This post has been edited by Nick.C: Jan 3 2008, 17:29


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post

50 Pages V  « < 26 27 28 29 30 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th July 2014 - 13:47