
Recherche avancée
Médias (10)
-
Demon Seed
26 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Demon seed (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
-
The four of us are dying (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
-
Corona radiata (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
-
Lights in the sky (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
-
Head down (wav version)
26 septembre 2011, par
Mis à jour : Avril 2013
Langue : English
Type : Audio
Autres articles (74)
-
Des sites réalisés avec MediaSPIP
2 mai 2011, parCette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page. -
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)
Sur d’autres sites (12053)
-
avcodec/vc1 : Arm 32-bit NEON deblocking filter fast paths
31 mars 2022, par Ben Avisonavcodec/vc1 : Arm 32-bit NEON deblocking filter fast paths
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of the
time, and the complexity of the remaining cases fall somewhere in between.
Therefore, taking the average of the best and worst case timings is
probably a conservative estimate of the degree by which the NEON code
improves performance.vc1dsp.vc1_h_loop_filter4_bestcase_c : 19.0
vc1dsp.vc1_h_loop_filter4_bestcase_neon : 48.5
vc1dsp.vc1_h_loop_filter4_worstcase_c : 144.7
vc1dsp.vc1_h_loop_filter4_worstcase_neon : 76.2
vc1dsp.vc1_h_loop_filter8_bestcase_c : 41.0
vc1dsp.vc1_h_loop_filter8_bestcase_neon : 75.0
vc1dsp.vc1_h_loop_filter8_worstcase_c : 294.0
vc1dsp.vc1_h_loop_filter8_worstcase_neon : 102.7
vc1dsp.vc1_h_loop_filter16_bestcase_c : 54.7
vc1dsp.vc1_h_loop_filter16_bestcase_neon : 130.0
vc1dsp.vc1_h_loop_filter16_worstcase_c : 569.7
vc1dsp.vc1_h_loop_filter16_worstcase_neon : 186.7
vc1dsp.vc1_v_loop_filter4_bestcase_c : 20.2
vc1dsp.vc1_v_loop_filter4_bestcase_neon : 47.2
vc1dsp.vc1_v_loop_filter4_worstcase_c : 164.2
vc1dsp.vc1_v_loop_filter4_worstcase_neon : 68.5
vc1dsp.vc1_v_loop_filter8_bestcase_c : 43.5
vc1dsp.vc1_v_loop_filter8_bestcase_neon : 55.2
vc1dsp.vc1_v_loop_filter8_worstcase_c : 316.2
vc1dsp.vc1_v_loop_filter8_worstcase_neon : 72.7
vc1dsp.vc1_v_loop_filter16_bestcase_c : 62.2
vc1dsp.vc1_v_loop_filter16_bestcase_neon : 103.7
vc1dsp.vc1_v_loop_filter16_worstcase_c : 646.5
vc1dsp.vc1_v_loop_filter16_worstcase_neon : 110.7Signed-off-by : Ben Avison <bavison@riscosopen.org>
Signed-off-by : Martin Storsjö <martin@martin.st> -
ffmpeg Padding & Delay to Audio File Accurately
14 avril 2022, par Ry-Recently I've been doing a personal project which does entail a little bit of
audio handling but I have noticed that the commands that I am using to modify
don't have a 1:1 correlation in the resulting file leading to it being fairly
offbeat (Note that this program is error sensitive).


All I need to do is accurately add Padding to the start of an audio file, or
jumpforward to some point in the song using an Offset/Delay value. The values
are strictly accurate such as 0.13149s however accuracy passed the third radix
is pretty redundant since 'nobody' should be able to notice it.


Here is an example of one issue:

 [Input File Info] // This is a test case/correct values
 Supposed to start at : 0.875
 Originally started at: 1.190
 Offset Value : -0.315
 Difference : 1.190 - 0.875 = 0.315



// Audio file offset attempt (FAIL)
 FFMPEG Command: 
 ffmpeg -y -i "..." -ss 0.315 -c copy -map 0 "..."
 
 [Output File Info]
 Start Time Beat : 0.766 
 Start Time Beat Audacity: 0.766
 Resulting Error : 0.106



What I want to know is if someone knows a better way to get 1:1 accuracy from
the command or atleast as close to it as possible. I don't often use ffmpeg so
I probably am missing vital information (I did my best googling ok :) but to
this I also wouldn't abstain from using a dedicated audio library for the
language I'm writing the program in (Java).


I probably should mention that I have been using:
 ffmpeg -y -i "..." -af "adelay=DELAY" "..."

to add the padding but I haven't really gotten around to testing audio files
that require this yet so I don't know if its broken/inaccurate.



-
avcodec/vc1 : Arm 64-bit NEON deblocking filter fast paths
31 mars 2022, par Ben Avisonavcodec/vc1 : Arm 64-bit NEON deblocking filter fast paths
checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C
version can still outperform the NEON version in specific cases. The balance
between different code paths is stream-dependent, but in practice the best
case happens about 5% of the time, the worst case happens about 40% of the
time, and the complexity of the remaining cases fall somewhere in between.
Therefore, taking the average of the best and worst case timings is
probably a conservative estimate of the degree by which the NEON code
improves performance.vc1dsp.vc1_h_loop_filter4_bestcase_c : 10.7
vc1dsp.vc1_h_loop_filter4_bestcase_neon : 43.5
vc1dsp.vc1_h_loop_filter4_worstcase_c : 184.5
vc1dsp.vc1_h_loop_filter4_worstcase_neon : 73.7
vc1dsp.vc1_h_loop_filter8_bestcase_c : 31.2
vc1dsp.vc1_h_loop_filter8_bestcase_neon : 62.2
vc1dsp.vc1_h_loop_filter8_worstcase_c : 358.2
vc1dsp.vc1_h_loop_filter8_worstcase_neon : 88.2
vc1dsp.vc1_h_loop_filter16_bestcase_c : 51.0
vc1dsp.vc1_h_loop_filter16_bestcase_neon : 107.7
vc1dsp.vc1_h_loop_filter16_worstcase_c : 722.7
vc1dsp.vc1_h_loop_filter16_worstcase_neon : 140.5
vc1dsp.vc1_v_loop_filter4_bestcase_c : 9.7
vc1dsp.vc1_v_loop_filter4_bestcase_neon : 43.0
vc1dsp.vc1_v_loop_filter4_worstcase_c : 178.7
vc1dsp.vc1_v_loop_filter4_worstcase_neon : 69.0
vc1dsp.vc1_v_loop_filter8_bestcase_c : 30.2
vc1dsp.vc1_v_loop_filter8_bestcase_neon : 50.7
vc1dsp.vc1_v_loop_filter8_worstcase_c : 353.0
vc1dsp.vc1_v_loop_filter8_worstcase_neon : 69.2
vc1dsp.vc1_v_loop_filter16_bestcase_c : 60.0
vc1dsp.vc1_v_loop_filter16_bestcase_neon : 90.0
vc1dsp.vc1_v_loop_filter16_worstcase_c : 714.2
vc1dsp.vc1_v_loop_filter16_worstcase_neon : 97.2Signed-off-by : Ben Avison <bavison@riscosopen.org>
Signed-off-by : Martin Storsjö <martin@martin.st>