Vienna Symphonic Library Forum
Forum Statistics

200,902 users have contributed to 43,216 threads and 259,148 posts.

In the past 24 hours, we have 2 new thread(s), 10 new post(s) and 58 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries (legacy)
  4. Native 48kHz samples vs 44.1kHz

  • Native 48kHz samples vs 44.1kHz

    A
    A
    since VI sample set is 44.1kHz/24bit, how much processing power it takes to just to perform SRC on the go in 48k projects?

    48k is the film industry standard and film composers use probably the largest counts of VI instances per session. Wouldn't it be more efficient to release a native 48k sample set for those who work with picture?
  • cmC
    VSL Team
    cmC
    abel, at some current opportunity on a system which actually could be not named *reference* it indicated to be about 30%. on a straight forward configured system it should be even less.
    to have a sample library at 48 kHz would in turn bring up the question why not 44.1 ...
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • A
    A
    sure, I understand your point, but even less then 30% is still a lot (lower buffer sizes, lower latency) and thinking about which customer group can actually afford the whole SC, I would bet on film composers.

    Why don't you just release a raw 48k version to the main suppliers in LA (West LA Music, Guitar Center) and they would take care of the distribution. No dvds to release, no reprogramming, just a simple conversion of the sample pool.
  • cmC
    VSL Team
    cmC
    last edited
    last edited

    @Abel said:

    Why don't you just release a raw 48k version to the main suppliers in LA (West LA Music, Guitar Center) and they would take care of the distribution. No dvds to release, no reprogramming, just a simple conversion of the sample pool.

    this statement gave me a good laugh ... let me dig out my remaining diplomacy to say: i think they are already buisy enough selling and delivering the items, occasionally installing and supporting a library, i can't imagine anyone would find the time to configure, compile and test the instruments ...

    the rough figure of 30% has been noticed by sheer chance on a certain configuration, as mentioned it should usually be less.
    basically the CPU load for ViennaInstruments is very low - as example 40 instances on a quad core XEON (2 x dual core) on XP hosted in cubase did use not even 10% of total CPU, so actually 30% more would be tolerable ...
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • A
    A
    wrong choice of words...
    by "raw" I meant vsl .dat format recompiled by the Vienna team, but released the OEM style, without a box. And I'm not saying it should be free.

    and what buffer sizes were used for the configuration you've mentioned?
    I'm on an 8-core Mac Pro and for 30 instances I cannot go below 512-sample buffer (RME Fireface800).
  • cmC
    VSL Team
    cmC
    regarding the *raw* version: you have to know the samples are stored in 96 kHz 32bit, so every other format would need a resampling cycle (for which VSL is using a proprietary tool to keep the high quality) and i guess nobody here would voluntarily process the almost 1.5 mio samples and the following steps ...

    buffer size ... hmm, this has been an ASIO 2 driver and i can't find a note now about the used buffer size, sorry. there are also other factors to consider and i should have mentioned the harddisks were striped sATA II (~ 4,5 ms average seektime) on an intel raidcontroller.
    on an 8-core mac you should have pretty much CPU left, no?
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • A
    A
    I don't understand this technical things,
    but the Activity Monitor shows 35-40% of cpu use (6% User + 30%System), regardless the buffer size of 256 or 512 samples.

    The only thing that really counts is the ASIO monitor (Cubase4) which overloads at 256 samples and 30 VI instances.

    with 9GB of RAM and I didn't reach the ceiling yet.
  • cmC
    VSL Team
    cmC
    ASIO overload means basically that audio data cannot be delivered *in time* to the device, which can have several reasons.
    whereas formerly in most cases the PCI-bus was the bottleneck it can be any bus between your drive having stored the sample data and the audio output - a few things to consider:
    - you should not record to the same drive you are reading sample data from
    - make sure your drive is able to deliver the requested amount of data
    - make sure you don't have any other firewire device on the same FW-bus
    - latest drivers, audio settings properly configured (eg. not 2 applications share ASIO)

    though you might not like another technical hint: one stereo voice needs 176 kB/s, in certain cases (eg. crossfades) even more and you should not expect signifcantly more than 25 MB/s throughput from a single harddisk at average access for sample streaming. do not rely on marketing-speech like *up to 100 MB/s* or similar, such figures are meant as boosts from the cache.
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • A
    A
    the numbers I've quoted were in "stop" mode (not playing),
    so there's nothing to read yet...

    when I hit play the ASIO meter jumps up only a little.

    anyway I have 4 SATA2 drives - system, projects/audio, vsl1, vsl2
    + video on ext. FW800

    the Fireface runs on FW400
  • J
    J
    last edited
    last edited

    @Abel said:

    48k is the film industry standard


    Not too sure about that...

    J.
  • A
    A
    last edited
    last edited

    @Abel said:

    48k is the film industry standard


    Not too sure about that...

    J.

    please elaborate.
  • cmC
    VSL Team
    cmC
    jerome, i remember at least earlier media compser and symphony have been always kind of troublesome (in detail the meridien board) with 44,1, especially if somewhen (eg. for rushes) DV or digiBETA was in the game - but i'm not at all up to date here ...
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • cmC
    VSL Team
    cmC
    abel, unfortunately we continue to be technical ...
    it is said that the firewire controller has only different ports and does internally not seperate the FW 800 and the FW400 bus (relying on the built-in downword capability instead of having different controllers) - it would be at least worth a try to reverse connections, i.e. fireface 800 on the FW800 and the harddisk on FW400. for video streaming the FW400 is still faster than data could be delivered from a single harddisk.
    in no case i would chain the devices.
    usually the RME fireface is not very sensitive having also a harddisk on the same controller, but who knows ....
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • H
    H
    http://techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1">http://techreport.com/reviews/2006q1/gigabyte-iram/index.x?pg=1

    To add to the discussion....
  • cmC
    VSL Team
    cmC
    yep, great concept - we already have some here (though it has not been easy to find a vendor) ... but my approach was more to use this device for the pagefile and i don't get it now how it might be related to this thread?
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    last edited
    last edited

    @Abel said:

    please elaborate.


    You didn't elaborate yourself... [:)]

    But I work in the film industry as a film composer / orchestrator / technician and out of all the people I know or worked for, I can say 48k is far from being the "industry standard" you're refering to.

    Some people work solely in 44.1k, some in 48k, and some switch between various sample rates.

    It's just not like *everybody* is working at 48Khz... it's as much a standard as 44.1Khz.
  • DietzD
    VSL Team
    DietzD
    Hardware-wise, 48 kHz is defacto the accepted standard for audio in the video-world. This is not due to the higher audio-standards in this part of the business, as one might assume (quite the contrary!), but due to the fact that 48 kHz encodes much easier in a video-stream.

    Of course, people working _for_ video in the audio-world often use 44.1, which has to get converted to 48 at some point, though.

    (Edited for typos [:P])
    /Dietz - Vienna Symphonic Library
  • G
    G
    last edited
    last edited

    @Dietz said:

    ..., which has to get coverted to 48 at some point, though.


    Yes.

    If you don't have to run against a 48k digital clock, refrain from realtime upsampling.

    You will get far better results converting the finished mix with a high order interpolation tool.

    In realtime operation there are quality vs speed tradeoffs.

    /c
  • J
    J
    last edited
    last edited

    @Dietz said:

    Of course, people working _for_ video in the audio-world


    who cares about anyone else? [:P]

    J.