Linux-audio-dev February 2006

linux-audio-dev@lists.linuxaudio.org

74 participants
63 discussions

[linux-audio-dev] Re: open standards for file formats

by Item State

hello, yes, peak/overview files and metadata is two different things. metadata should be stored in a open and extensible format such as XML. the problem with peak files is, different programmes rely on different resolution and representation. to give an example, in eisenkraut i use four peak files in four decimation scales ; only the highest resolution (1:256 (?)) is saved permanently, the others are created on the fly. since i want to support floating point files, i decided to store peak waveform in float32 format, which is rather big ; other sound editors will decide to not do this. also i store both peak and RMS information, others wish to store only peak, or peak and spectral focus or whatever. so unless two programmes are rather similiar, i wouldn't be too optimistic about using a uniform peak display. also i wouldn't deal with commercial software, honestly. if two software companies, say bias (for peak) and emagic/apple (for logic) are too dumb to agree on one format, i see no point why open source software should go and beg those companies to share their format. rather, if there are a few de facto standard open source softwares, it would make sense that they define a standard that they share. for eisenkraut i use normal AIFF files als overviews, i think that's pretty straight format, and since most programmes will store some form of PCM data, it shouldn't be too difficult to sync two -- if they work in a similar resolution and representation. there are some standards already, like SDIF for spectral information for example. best, -sciss- ____________________________________________________ Do you Yahoo!? Never miss an Instant Message - Yahoo! Messenger for SMS http://au.mobile.yahoo.com/mweb/index.html

18 years, 10 months

[linux-audio-dev] Re: [linux-audio-user] rosegarden dssi problem

by Emanuel Rumpf

Chris Cannam wrote: >On Tuesday 24 Jan 2006 13:17, Emanuel Rumpf wrote: > > >>The problem occures on all files, that have dssi-plugins assigned. >>Here is a simple test file with a track "bass" that has the "Less >>trivial synth" applied. >>If I open and play it, there is no sound. >> >> > >I can't reproduce this at all. The example file works fine for me. That's >rather troubling. > >Did you build this from CVS yourself? Are you in a position to build it again >with some debug output enabled? If so, I'd like to see what is printed by >the sequencer process when the two lines > >#define DEBUG_DSSI 1 >#define DEBUG_DSSI_PROCESS 1 > >at the top of sound/DSSIPluginInstance.cpp are uncommented. > > >Chris > > > Did the output I've sent help somehow? Has anyone else reported a similar problem? If this is related to my system only, do you have any idea why/how this could be? Dssi is working on my system, also in rosegarden, only when loading a new file, the tracks with dssi-plugins are muted somehow... then I have to re-assign the plugins for each track for the sound to come back. Emanuel

18 years, 10 months

[linux-audio-dev] Re: [linux-audio-user] LAD site, linuxdj.com needs a new home

by Benno Senoner

I mailed Paul the link to fetch the whole LAD web tree and files, about 5.7GB ( the content that was on www.linuxdj.com/audio ) next step should be deciding wheter to put the content on a nicer domain. ( and having linuxdj.com/audio redirect to that domain/site so that search engine and website links get redirected to the correct place). I'll wait for Paul's reply how to proceed (redirect linuxdj.com etc). cheers, Benno Paul Davis wrote: >On Mon, 2006-01-30 at 17:44 -0500, Paul Davis wrote: > > >>On Tue, 2006-01-31 at 01:10 +0100, Esben Stien wrote: >> >> >>>Benno Senoner <sbenno(a)gardena.net> writes: >>> >>> >>> >>>>consumes so much bandwidth >>>> >>>> >>>Why don't we put these videos on archive.org?. >>> >>> >>I currently have 1870GB/month bandwidth, and it climbs by 16GB/week >>right now. Last month, I used 0.1% of my bandwidth. Its not an issue. >> >> > >lets get this transfer started ... > > > >

18 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev February 2006