similar to: FW: Lossy music formats compared

Displaying 16 results from an estimated 16 matches similar to: "FW: Lossy music formats compared"

2023 Apr 15
1
Transcode lossy to further reduced lossy to stream over Icecast
Situation:? * remote virtual server with very little storage (estimate: I can spare about 40G for music) * local music collection of ~80G in all sorts of formats - lossy in varying quality, some lossless too Vision: * stream my whole music collection randomized so I can listen to it anywhere Plan/Idea: * Locally transcode everything to one format that results in files that are?
2023 Apr 15
1
Transcode lossy to further reduced lossy to stream over Icecast
Opus or AAC will give you comparable results at reasonable bitrates (~128k). Though, I would suggest finding a way to get more storage. You could upload to Backblaze B2 or AWS S3 for pennies, if your current host won't let you upgrade. On Sat, Apr 15, 2023 at 3:36?PM D.T. <ohnonot-github at posteo.de> wrote: > Situation: > > - remote virtual server with very little
2023 Apr 16
1
Transcode lossy to further reduced lossy to stream over Icecast
I created some test samples and transcoded to FDK AAC and libopus at fairly low bitrates - I cannot recreate what bothered me about Opus & noisy music previously. It also seems I cannot tease ffmpeg into encoding FDK's AAC with VBR. As it stands, Opus clearly wins in this scenario.* Q: Is it possible to stream in variable bitrate? * ffmpeg -i "$track" -vn -ac 2 -c:a libfdk_aac
2020 Jan 08
0
Re: [PATCH] Fix lossy conversion of Content-Length
On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote: > Actual variable holding content length is int64_t, but it was assigned > by explicit cast to size_t. On 32-bit systems it's a lossy conversion, > so it was replaced by casting to int64_t instead. > > Signed-off-by: Adrian Ambrożewicz <adrian.ambrozewicz@linux.intel.com> > --- >  plugins/curl/curl.c | 2 +- >  1 file
2020 Jan 09
0
Re: [PATCH] Fix lossy conversion of Content-Length
W dniu 1/9/2020 o 14:07, Richard W.M. Jones pisze: > On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote: >> On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote: >>> Actual variable holding content length is int64_t, but it was assigned >>> by explicit cast to size_t. On 32-bit systems it's a lossy conversion, >>> so it was replaced by casting to int64_t
2020 Jan 10
0
Re: [PATCH v2] Fix lossy conversion of Content-Length
Thanks - I have pushed this now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
2020 Jan 10
0
[PATCH v2] Fix lossy conversion of Content-Length
From a120342e0d3d20962396e6bf5bd5ac30c66b5983 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adrian=20Ambro=C5=BCewicz?= <adrian.ambrozewicz@linux.intel.com> Date: Tue, 7 Jan 2020 11:07:08 +0100 Subject: [PATCH 1/1] Fix lossy conversion of Content-Length MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Actual variable holding content length is int64_t,
2011 Jan 08
0
Detecting lossy encodes
On Sat, Jan 08, 2011 at 12:54:01AM +0100, jorgen at anion.no wrote: > > I think we agree now on that the "find mp3 before encoding" feature would not be a good idea to implement in the flac core. As Brian pointed out, it might be a better idea to create a program that automatically checks if a flac might have been an mp3 source. It would be more versatile to check if the
2001 Feb 27
0
[Q] Lossy compression background information book?
Does anybody have a 'net or hardcopy reference for basic information about the sorts of compression Vorbis uses? It sounds like there's a lot of interesting math hiding in there... Thanks, d. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-request@xiph.org'
2011 Jan 08
0
Detecting lossy encodes
Brian Willoughby <brianw at sounds.wa.com> wrote: > On Jan 7, 2011, at 16:27, Declan Kelly wrote: ... >> As the human hearing can't really tell direction with lower >> frequencies, >> it's not as essential. This same shortcut is why most movie "surround >> sound" systems have only one sub bass channel. > > In this case, you have been misled
2020 Jan 09
2
Re: [PATCH] Fix lossy conversion of Content-Length
On Thursday, 9 January 2020 17:41:58 CET Adrian Ambrożewicz wrote: > W dniu 1/9/2020 o 14:07, Richard W.M. Jones pisze: > > On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote: > >> On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote: > >>> Actual variable holding content length is int64_t, but it was assigned > >>> by explicit cast to size_t. On 32-bit
2001 Nov 01
1
Lossy Audio Compression Research
Hello everyone, I'm a student at the Universtiy of Delaware, and will be soon starting some research on the effects of lossy audio compression on speech sounds. I will be preforming test with both mp3 and vorbis. First of all, if I use the '--ogg' switch to lame, does lame use GPSYCHO to encode the wave, or some other psychoacoustic model (perhaps one designed for
2020 Jan 07
3
[PATCH] Fix lossy conversion of Content-Length
Actual variable holding content length is int64_t, but it was assigned by explicit cast to size_t. On 32-bit systems it's a lossy conversion, so it was replaced by casting to int64_t instead. Signed-off-by: Adrian Ambro?ewicz <adrian.ambrozewicz at linux.intel.com> --- plugins/curl/curl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/curl/curl.c
2020 Jan 09
2
Re: [PATCH] Fix lossy conversion of Content-Length
On Wed, Jan 08, 2020 at 07:19:56AM -0600, Eric Blake wrote: > On 1/7/20 4:13 AM, Adrian Ambrożewicz wrote: > >Actual variable holding content length is int64_t, but it was assigned > >by explicit cast to size_t. On 32-bit systems it's a lossy conversion, > >so it was replaced by casting to int64_t instead. > > > >Signed-off-by: Adrian Ambrożewicz
2001 May 30
3
Lossless/lossy hybrid?
Monkey's Audio lossless compressor (currently win32 only, free but not open-source except decoder) author is thinking to implement a kind of audiophile-quality lossy compression which would filter "noise bits" that are hard to encode lossless but which are (or should be) inaudible and thus improve lossless compression (avg. 300-450kbps). I think that implementing something like this
2019 Jan 27
0
new -l16 "extreme" compression quality setting
Hello, I have added a new -l16 "extreme" compression quality setting to the NHW Project. This new -l16 quality setting is surprisingly good actually, because I find it better on some images than -l15 quality setting whereas files size is smaller.I notably find this new -l16 quality setting better than x265 (HEVC). More at: http://nhwcodec.blogspot.com/ We can still save 2.5KB per