In addition to Sample00931, which is very short, Sample00917 and Sample00918 appear to have problems. The video/skeleton data have a different length than the audio data. It looks like the problem is that the video/skeleton data is running too slow.
\n\n
I downloaded from the UOC mirror at http://sunai.uoc.edu/chalearn/.
\n\n
Let us know how we should handle these three files, or if you plan to fix them. Thanks.
\n", "messages": [ { "id": "29074", "postDate": "08/20/2013 16:51:45", "content": "
In addition to Sample00931, which is very short, Sample00917 and Sample00918 appear to have problems. The video/skeleton data have a different length than the audio data. It looks like the problem is that the video/skeleton data is running too slow.
\n\n
I downloaded from the UOC mirror at http://sunai.uoc.edu/chalearn/.
\n\n
Let us know how we should handle these three files, or if you plan to fix them. Thanks.
\n", "rawMarkdown": "", "votes": null }, { "id": "29108", "postDate": "08/21/2013 02:07:39", "content": "
wweight,
\n\n
I have discovered the same problem with yours. In Sample00917, audio data has 1055873 elements, while skeleton data has 1981 element, which indicates that the skeleton sample rate is likely to be 30Hz rather than 20Hz. Sample00918 has the similar problem. Hopefully the admins will come up with a solution soon.
\n\n
Jiaxiang Wu
", "rawMarkdown": "", "votes": null }, { "id": "29135", "postDate": "08/21/2013 09:48:19", "content": "We are checking the files you are reporting. The easiest solution is to down-sample the skeleton data.
\nXavier
", "rawMarkdown": "", "votes": null }, { "id": "29195", "postDate": "08/21/2013 21:37:09", "content": "> The easiest solution is to down-sample the skeleton data.
\n\n
Since we don't know by what factor the skeleton data is wrong, and since many algorithms depend on that sample rate being correct, I don't think that would work.
\n\n
If it's difficult to fix the source files for these three Samples, then maybe these three simply shouldn't be counted (i.e. Edit Distance = 0, independent of what we submit for these Samples).
\n", "rawMarkdown": "", "votes": null }, { "id": "29230", "postDate": "08/22/2013 11:22:56", "content": "
Dear wweight,
\nif some of the samples have hard issues, we will take it into account on the final evaluation.
\n\n
Xavier
", "rawMarkdown": "", "votes": null } ], "comments": [ { "id": 29108, "author_name": "jiaxiangwu", "author_url": "", "post_date": "08/21/2013 02:07:39", "content": "wweight,
\n\n
I have discovered the same problem with yours. In Sample00917, audio data has 1055873 elements, while skeleton data has 1981 element, which indicates that the skeleton sample rate is likely to be 30Hz rather than 20Hz. Sample00918 has the similar problem. Hopefully the admins will come up with a solution soon.
\n\n
Jiaxiang Wu
", "votes": null, "replies": [] }, { "id": 29135, "author_name": "xbaro100272", "author_url": "", "post_date": "08/21/2013 09:48:19", "content": "We are checking the files you are reporting. The easiest solution is to down-sample the skeleton data.
\nXavier
", "votes": null, "replies": [] }, { "id": 29195, "author_name": "rkeisler", "author_url": "", "post_date": "08/21/2013 21:37:09", "content": "> The easiest solution is to down-sample the skeleton data.
\n\n
Since we don't know by what factor the skeleton data is wrong, and since many algorithms depend on that sample rate being correct, I don't think that would work.
\n\n
If it's difficult to fix the source files for these three Samples, then maybe these three simply shouldn't be counted (i.e. Edit Distance = 0, independent of what we submit for these Samples).
\n", "votes": null, "replies": [] }, { "id": 29230, "author_name": "xbaro100272", "author_url": "", "post_date": "08/22/2013 11:22:56", "content": "
Dear wweight,
\nif some of the samples have hard issues, we will take it into account on the final evaluation.
\n\n
Xavier
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "29074": "", "29108": "", "29135": "", "29195": "", "29230": "" }, "source": "meta" }