Comments (7)
dpwe
commented on July 20, 2024
It could be that the mp3 decoder gives a slightly different result on the
two architectures. Try converting the query to an afpk file (preprocessed
peaks) then run the query on both machines; the results should be the same.
MP3 decoders (even different versions of mpg123) can differ in their net
delay, and an identically-timed query will get many more hits than a random
time alignment.
DAn.
…On Sun, Nov 6, 2022 at 13:06 CoenGoedhart1 ***@***.***> wrote:
—
Reply to this email directly, view it on GitHub
<#92>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUPF3NCCSRY4BQKK64TWG7XRFANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
from audfprint.
CoenGoedhart1
commented on July 20, 2024
Hi, thanks for responding. I did some tests. having the same query and database on both windows and linux. I tried with the original mp4 files, afpk files (the peaks) and the precomputed afpt files. On windows the mp4 query finds significantly more matches with the mp4 files than the aftp and afpk files. both afpk and afpt outputs are identical on windows and linux. Linux finds also siginificantly more matches with the mp4 comparing to aftp and afpk. However linux mp4 finds less matches than windows mp4. On both machines i installed the newest ffmpeg available. My goal is to find the same exact matches on my linux system as the matches i found on windows using the mp4 files.
"MP3 decoders (even different versions of mpg123) can differ in their net
delay, and an identically-timed query will get many more hits than a random
time alignment."
can i conclude from this that a possible solution could be to build up the entire database on the linux system since creating the database on a different platform could interfere the delay?
from audfprint.
dpwe
commented on July 20, 2024
That's puzzling, but I think your results point to differences in the audio
codec on the different platforms.
If you're querying with the originals, your very-high matches may be
illusory: If the reference and query are the exact same audio (through the
same codec) or an exact prefix, then all the hashes will match - something
that will never happen with a real, independent query. So I wouldn't get
too hung up on those numbers. If the query is actually a separate audio,
my guess would be the match count would be equivalent (on average, though
perhaps not identical) on both platforms. I wouldn't expect a significant
difference between which platform you built the database on, and I don't
think it's a big problem to mix reference items ingested on both platforms.
But I'm not sure, and your empirical results are interesting.
DAn.
…On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 ***@***.***> wrote:
Hi, thanks for responding. I did some tests. having the same query and
database on both windows and linux. I tried with the original mp4 files,
afpk files (the peaks) and the precomputed afpt files. On windows the mp4
query finds significantly more matches with the mp4 files than the aftp and
afpk files. both afpk and afpt outputs are identical on windows and linux.
Linux finds also siginificantly more matches with the mp4 comparing to aftp
and afpk. However linux mp4 finds less matches than windows mp4. On both
machines i installed the newest ffmpeg available. My goal is to find the
same exact matches on my linux system as the matches i found on windows
using the mp4 files.
"MP3 decoders (even different versions of mpg123) can differ in their net
delay, and an identically-timed query will get many more hits than a random
time alignment."
can i conclude from this that a possible solution could be to build up the
entire database on the linux system since creating the database on a
different platform could interfere the delay?
—
Reply to this email directly, view it on GitHub
<#92 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you commented.Message ID:
***@***.***>
from audfprint.
dpwe
commented on July 20, 2024
Converting the queries to WAV instead of mp3/mp4 (then copying between
platforms) should also ensure they get into audfprint as the exact same
values, to further confirm that the codec is responsible.
DAn.
…On Mon, Nov 7, 2022 at 08:24 Dan Ellis ***@***.***> wrote:
That's puzzling, but I think your results point to differences in the
audio codec on the different platforms.
If you're querying with the originals, your very-high matches may be
illusory: If the reference and query are the exact same audio (through the
same codec) or an exact prefix, then all the hashes will match - something
that will never happen with a real, independent query. So I wouldn't get
too hung up on those numbers. If the query is actually a separate audio,
my guess would be the match count would be equivalent (on average, though
perhaps not identical) on both platforms. I wouldn't expect a significant
difference between which platform you built the database on, and I don't
think it's a big problem to mix reference items ingested on both platforms.
But I'm not sure, and your empirical results are interesting.
DAn.
On Mon, Nov 7, 2022 at 7:55 AM CoenGoedhart1 ***@***.***>
wrote:
> Hi, thanks for responding. I did some tests. having the same query and
> database on both windows and linux. I tried with the original mp4 files,
> afpk files (the peaks) and the precomputed afpt files. On windows the mp4
> query finds significantly more matches with the mp4 files than the aftp and
> afpk files. both afpk and afpt outputs are identical on windows and linux.
> Linux finds also siginificantly more matches with the mp4 comparing to aftp
> and afpk. However linux mp4 finds less matches than windows mp4. On both
> machines i installed the newest ffmpeg available. My goal is to find the
> same exact matches on my linux system as the matches i found on windows
> using the mp4 files.
>
> "MP3 decoders (even different versions of mpg123) can differ in their net
> delay, and an identically-timed query will get many more hits than a
> random
> time alignment."
>
> can i conclude from this that a possible solution could be to build up
> the entire database on the linux system since creating the database on a
> different platform could interfere the delay?
>
> —
> Reply to this email directly, view it on GitHub
> <#92 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEGZUOGWCN34U7OBZKPJQTWHD343ANCNFSM6AAAAAARYRCJOY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
from audfprint.
CoenGoedhart1
commented on July 20, 2024
I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux, 1 virtual linux docker system. I created a database using the pi and have 585 queries with audio downloaded from a different source. In the database are the original videos and the queries are tweets, so it's not the original files. I found out that it does not matter on which system you create the database. I created one on linux and one on windows. when using the one on the other system results stay consistent. So, adding mp4 files to the database is for all platforms the same. Only the reuslts of the query are different. The docker and pi outputs exactly the same. The windows system finds significantly more matches.
I also tried to converting to wav.
On the windows machine i did the following mpeg command:
for %i in (*.mp4) do ffmpeg -i "%i" "%~ni.wav"
when querying windows had the same results but linux did far worse then the mp4 files.
On the linux machine i also converted the same mp4 files to wav:
for i in .mp4; do ffmpeg -i "$i" "${i%.}.wav"; done
transfering to windows and querying again gave the same good results, on linux the same bad results.
I think it can only be ffmpeg right? im not sure how to investigate further
from audfprint.
dpwe
commented on July 20, 2024
Yes, I think it's the encoding of the queries and differences in the codec
on linux/windows. It may be a licensing thing - Windows may have a
high-quality, commercial decoder, but linux may be limited to an inferior
open-source one. And it might be different for the queries (from tweets)
but the same for the reference items because of a different codec being
used for the audio from the two sources.
One way to debug further would be to duplicate the query decoding being
performed by audfprint, then look closely at the debug output from ffmpeg
on each platform to see what library it reports using.
It should just be "ffmpeg -i <input_file> -f s16le -ac 1 -ar 11025
out.pcm". For example, on my machine I get:
***@***.***:~/Downloads$ ffmpeg -i solo.mp3 -f s16le -ac 1 -ar
11025 out.pcm
ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 14.0.0 (clang-1400.0.29.102)
configuration: --prefix=/usr/local/Cellar/ffmpeg/5.1.2 --enable-shared
--enable-pthreads --enable-version3 --cc=clang --host-cflags=
--host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl
--enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame
--enable-libopus --enable-librav1e --enable-librist --enable-librubberband
--enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora
--enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx
--enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2
--enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype
--enable-frei0r --enable-libass --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex
--enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack
--disable-indev=jack --enable-videotoolbox
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100
Input #0, mp3, from 'solo.mp3':
Metadata:
encoder : Lavf56.15.102
Duration: 00:00:14.86, start: 0.025057, bitrate: 64 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 64 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (mp3float) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, s16le, to 'out.pcm':
Metadata:
encoder : Lavf59.27.100
Stream #0:0: Audio: pcm_s16le, 11025 Hz, mono, s16, 176 kb/s
Metadata:
encoder : Lavc59.37.100 pcm_s16le
size= 320kB time=00:00:14.83 bitrate= 176.4kbits/s speed=1.02e+03x
video:0kB audio:320kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.000000%
I'm actually not sure how to pick out the mp3 decoder there, but it would
be interesting to compare the results for running on Windows and Linux
anyway.
DAn.
…On Mon, Nov 7, 2022 at 4:15 PM CoenGoedhart1 ***@***.***> wrote:
I did some more testing. I now have 3 systems, 1 winsows, 1 pi with linux,
1 virtual linux docker system. I created a database using the pi and have
585 queries with audio downloaded from a different source. In the database
are the original videos and the queries are tweets, so it's not the
original files. I found out that it does not matter on which system you
create the database. I created one on linux and one on windows. when using
the one on the other system results stay consistent. So, adding mp4 files
to the database is for all platforms the same. Only the reuslts of the
query are different. The docker and pi outputs exactly the same. The
windows system finds significantly more matches.
I also tried to converting to wav.
On the windows machine i did the following mpeg command:
for %i in (*.mp4) do ffmpeg -i "%i" "%~ni.wav"
when querying windows had the same results but linux did far worse then
the mp4 files.
On the linux machine i also converted the same mp4 files to wav:
for i in *.mp4; do ffmpeg -i "$i" "${i%.*}.wav"; done
transfering to windows and querying again gave the same good results, on
linux the same bad results.
I think it can only be ffmpeg right? im not sure how to investigate further
—
Reply to this email directly, view it on GitHub
<#92 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEGZUKUT7GWGSE2G4TYSK3WHFWPHANCNFSM6AAAAAARYRCJOY>
.
You are receiving this because you commented.Message ID:
***@***.***>
from audfprint.
CoenGoedhart1
commented on July 20, 2024
Hi DAn, thank you so much! I did manage to recreate the results of the windows machine on the raspberri pi. Converting the mp4 files to wav with the sample rate of 11025 and having FFMPEG on False on the audio_read.py gave me the exact same results. Im looking into using the same decoder on both platforms but for now i have a workable solution! Again, thnx for your help!
from audfprint.
Related Issues (20)
- How to Debug a Non Match HOT 5
- Multiple input and adding live audio option HOT 3
- Incorrect time range HOT 1
- Incorrect Time range. HOT 1
- Convert .afpk files to mp3? HOT 1
- Problem with "spreadpeaksinvector"
- Reduce memory usage HOT 2
- Use audfprint as a module
- How to increase bits for storing IDs and timestamp?
- illustrate
- Scan every folder in every fingerprint base named as folder HOT 3
- UNICODE chaaracters ERROR HOT 11
- Show more than 1 finded matched names in results. HOT 4
- Can this algorithm load the historical features into memory first, so that the matching speed is improved, but I don't know how to modify your basic code HOT 7
- Hello, if the song is 1 million (the duration of the song is about 3 minutes), the matching time is very slow, how to optimize it? HOT 1
- I found that according to The time and hash generated by audfprint are not continuous in time, which led me to use the binary method to search for the same hash, conduct a statistical ranking of the number of hashes, and search for the original version of individual audio (the climax audio), and the ranking is not the first.
- I found that some match matches are inaccurate. I want to know, is the time and hash generated by this audfprint continuous at the start-end time, or is it a peak value, which leads to the fact that if one song is 1 minute, another song 3 minutes, there are a lot of hashes in the previous minute in the last two minutes of the next song, which leads to the fact that the hash statistics are larger than one minute, resulting in inaccurate sorting, then the match situation is inaccurate, how to optimize this? HOT 2
- Question about concatenate afpk files HOT 2
- How to avoid big % Dropped HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from audfprint.